I just got done reading an excellent article by Roman Snitko. I agree almost 100% with everything he says. However, I felt that the idea could have been developed and executed better. I’m not writing this because I feel that his original piece sucked. Rather I’m writing this because I like the idea he comes up with and want to see it have an impact. So here’s my shot.
(I should say that some of what I say might disagree with what Roman says. I did say almost 100%.)
People tend to associate “engineers” with people who get things done and solve real-world problems. Thus, I feel that Roman’s “dudes” can be thought of as the engineers of the programming community. Engineers are the ones who want to make something and get it in peoples’ hands as quickly as possible. It just so happens that that product is a piece of software.
You can recognize an engineer because they’re usually saying things like “So what if it’s not perfect? It works!” or “That sounds like a great idea, but I don’t think we have time for it.”
The engineer’s biggest weakness is that they seem to not think about much past their current deadlines. Yes, it’s important to meet those deadlines. But you do plan on writing software after meeting those deadlines, don’t you? To make up for this, they must call upon the expertise of the scientist.
The interesting thing is that almost every field of engineering has a corresponding field of science. Scientists are people who find better ways of doing things without necessarily considering their practicality. It’s fashionable to talk about how disconnected these types of people are from reality, but the truth of the matter is that engineers can’t do the things they can without scientists. Scientists are the ones who want to build great software. It just so happens that that software is also a product people will use.
You can recognize scientists because they’re usually saying things like “So what if it works? It’s an ugly hack!” or “Software schedules should reflect what needs to get done, not the other way around.”
You might have already guessed the scientist’s weakness: they tend to not get along with deadlines very well. To make up for this, they must call upon the abilities of an engineer who can transform their great ideas into reality.
So who’s right?
This way of looking at things is a bit of an oversimplification though. It’s really not that engineers don’t want to make a great piece of software or that scientists don’t want to make a great product. It’s really a matter of priority. Scientists would rather write a great piece of software than a product. Engineers would rather make a product than a great piece of software.
Unfortunately, both sides are a bit disconnected from reality. In the software world, a great product usually is a great piece of software. It’s also unfortunate that someone who can make both things happen is extremely rare if not nonexistent.
Thus, it is ideal for these two sides to be in a state of healthy conflict. They need to recognize that the other side has a point sometimes (as hard as that can be).
So which one are you? And how do you work with the other side?