So the lesson from this is: if you want your economy to excel in the 21st century, for the IT, information-based high-tech sectors, a big banking sector, even a very successful banking system, is bad news for your economy. You could even argue based on this that the bigger the banking sector is, the worse is the news for your economy, because their magnetic attraction of taking engineers and technically qualified people and computer scientists into the banking sector is due to high bonuses and higher salaries prevents these creative growth sectors from realizing their full potential.
— Ólafur Ragnar Grímsson, President of Iceland
This is a particularly eye opening perspective that I had never thought of. From a guy who experienced it all. After being enlightened, I couldn’t help wonder how did I miss it; its right in front of my eyes.
Unlike Iceland, we still lives in an economy where the banks are the big boys, and some had said they are even bigger now.
I worries about our collective future.
Seeing Gangnam Style growing popularity reminds me of this quote from Steve Jobs:
When you’re young, you look at television and think, There’s a conspiracy. The networks have conspired to dumb us down. But when you get a little older, you realize that’s not true. The networks are in business to give people exactly what they want. That’s a far more depressing thought. Conspiracy is optimistic! You can shoot the bastards! We can have a revolution! But the networks are really in business to give people what they want. It’s the truth.
Patrick Wyatt wrote,
At some point I talked with Mark and Patrick about how Dominion Storm knocked us on our heels, and they let us in on Ion Storm’s dirty little secret: the entire demo was a pre-rendered movie, and the people who showed the “demo” were just pretending to play the game! It would be an understatement to say that we were gobsmacked; we had been duped into a rebooting StarCraft, which ultimately led it to be considered “the defining game of its genre. It is the standard by which all real-time strategy games are judged” (GameSpot).
Amazing piece about the development of Starcraft. Anyway start up serious about building a development studio (and not trying to build a one off product to sell off) should read this.
Patrick Wyatt wrote about his experience developing Starcraft and it isn’t pretty at all.
I am a big fan of Starcraft since I was 13. The game could easily be one of the reasons for why I pursue a career of programming, with a keen interest in game development (not at the moment though). Starcraft always seems like the benchmark game for the RTS genre, together with Warcraft, especially after I participated in the development of Deep Quest. I was thrilled to be able to get an insight into the development of Starcraft.
It really surprise me that the development of Starcraft is hectic. I was expecting something more “pretty and nice”, instead I get something I could relate to, a development situation I have been in for the longest time, even today.
I am not too bad a programmer as I have bagged 7-8 years of code writing experience at a regular interval but I observed that I haven’t move out much of such hectic situations before. It sadden me that in local (Singapore) development environment, we are still going through the same hectic process. Personally, I pick up tips to deal with such development situations, but it doesn’t shield you completely and I feel I’m getting paid dealing with these issues instead of solving real world problems.
The post really magnify a number of these issues and I list some of them here. To have a more complete picture, I recommend reading the whole post.
Complete everything in X hours/days/months
Given the number of game units and behaviors that needed to be added, the changes necessary to switch from top-down to isometric artwork, a completely new map editor, and the addition of Internet play over battle.net, it was inconceivable that the game actually could ship in that time, even assuming that the art team, designers, sound engineers, game-balancers and testers could finish their end of the bargain. But the programming team continually worked towards shipping in only two months for the next fourteen months!
Almost every project I worked on would have some variant of such ridiculous timeline, and every of them will eventually get slipped even after I already warned them. I always see these as a lack of understanding of the programming aspect of the development. It is (really!) a much more complicated process. I stop treating these requests with any real seriousness because some work just can’t be cut. This will often leads to…
The entire team worked long hours, with Bob working stretches of 40 hours, 42 hours, even 48 hours programming. As I recall no one else attempted these sorts of masochistic endeavors, though everyone was putting in massive, ridiculous hours.
My experiences developing Warcraft, with frequent all-nighters coding, and later Diablo, where I coded fourteen-plus hour days seven days a week for weeks at a time, suffered me to learn that there wasn’t any point in all-nighters. Any code submissions [ha! what an appropriate word] written after a certain point in the evening would only be regretted and rewritten in the clear light of following days.
Working these long hours made people groggy, and that’s bad when trying to accomplish knowledge-based tasks requiring an excess of creativity, so there should have been no surprises about the number of mistakes, misfeatures and outright bugs.
I still had to put in around 30+ hours from time to time. Sometimes, I don’t even bother putting in more hours precisely because, I quoted “Any code submissions [ha! what an appropriate word] written after a certain point in the evening would only be regretted and rewritten in the clear light of following days.” It other words, those code written will be wasted by the time i recuperated, and I will have to waste more time fixing my bugs. People who doesn’t understand will attempt to discredit you or give you the “you are such a lousy programmer” look and it annoy the hell out of me. It stroke my ego and I fall for these easily. When you are not shield by a project manager, these things happened.
Not solving the root of the problem because of ridiculous deadline
So after fixing many, many linked list bugs, I argued vehemently that we should switch back to using Storm’s linked lists, even if that made the save-game code more complicated. When I say “argued vehemently”, I should mention that was more or less the only way we knew how to argue at Blizzard — with our youthful brashness and arrogant hubris, there was no argument that wasn’t vehement unless it was what was for lunch that day, which no one much wanted to decide.
I didn’t win that argument. Since we were only “two months” from shipping, making changes to the engine for the better was regularly passed over for band-aiding existing but sub-optimal solutions, which led to many months of suffering, so much that it affected my approach to coding (for the better) ever since, which is what I’ll discuss in part two of this article.
Many people don’t buy the “taking the longer path now to save future effort” mantra, another things that annoy the hell out of me. It seems to me that for them, if they don’t see it now, its does not exists. Then these bugs just keep coming back to delay the projects and they start yelling at the top of their voice, “why this isn’t fixed! I thought we have worked on this before!” This is one of the most WTF moment a programmer have to endure in its career. But for me the most important thing is
Sacrificing personal health and family/friends life, putting unheard hours into the project for ?
The team was incredibly invested in the project, and put in unheard of efforts to complete the project while sacrificing personal health and family life. I’ve never been on a project where every member worked so fiercely. But several key coding decisions in the project, which I’ll detail presently, would haunt the programming team for the remainder of the project.
Often that not, this is not recognized. Even if it is recognized, it is not compensated. I put in my fair share of sacrifice. It’s like a ritual, you do it for nothing. I get to the point that its no longer worth it. Why get yourself hurt for nothing? But as a programmer you will keep doing that. It’s not for the recognition or compensation obviously, they never come, it’s for yourself. You don’t stop until its solved, isn’t it. But these issues add up.
As I read the post, I keep nodding towards the scenarios I could relate to. Starcraft development doesn’t seems too different from the many I have been through, but of course, the author doesn’t get lost in the dark path (as mentioned in his Guild Wars development), while I am a still in.
I didn’t have time to explains more but there’s several quotes I would like to highlights.
C++ is about having it all there at your fingertips. I found this quote on a C++11 FAQ:
The range of abstractions that C++ can express elegantly, flexibly, and at zero costs compared to hand-crafted specialized code has greatly increased.
That way of thinking just isn’t the way Go operates. Zero cost isn’t a goal, at least not zero CPU cost. Go’s claim is that minimizing programmer effort is a more important consideration.
Python and Ruby programmers come to Go because they don’t have to surrender much expressiveness, but gain performance and get to play with concurrency.
C++ programmers don’t come to Go because they have fought hard to gain exquisite control of their programming domain, and don’t want to surrender any of it. To them, software isn’t just about getting the job done, it’s about doing it a certain way.
The issue, then, is that Go’s success would contradict their world view.
Go have just go into my to-learn list with this.
If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition.
Apple gets a lot of ignorant hate, and a lot of ignorant reverence. Let me give some informed reverence for one area where they kick so much ass: accessibility.
Meanwhile, walking the talk…
I think subconsciously people are remarkably discerning. I think that they can sense care.
One of the concerns was that there would somehow be, inherent with mass production and industrialisation, a godlessness and a lack of care.
I think it’s a wonderful view that care was important – but I think you can make a one-off and not care and you can make a million of something and care. Whether you really care or not is not driven by how many of the products you’re going to make.
We’re keenly aware that when we develop and make something and bring it to market that it really does speak to a set of values. And what preoccupies us is that sense of care, and what our products will not speak to is a schedule, what our products will not speak to is trying to respond to some corporate or competitive agenda. We’re very genuinely designing the best products that we can for people.
— Jonathan Ive (Interview with Telegraph)