Updated: Additional clarification added to the bottom of the post.
I’m currently taking two Software Engineering Master’s courses. I’ll be graduating in May with a minor in Software Engineering, and I can say with absolute certainty that software engineering sucks.
I’m sitting in the back of one of my classes listening to a professor talk about software architectures. He’s explaining why and how architectures should be built. I can’t disagree with anything he’s saying…he’s talking about modular code and reusability, and explaining the levels of complexity of different types of architectures. That’s great, and I definitely see use for software engineering and how it can help make development simpler and easier. But software engineering sucks.
“But why does software engineering suck Brian?”
Software Engineering Does Not Promote Innovation
This can be summed up in a quote by a fellow student in one of my SE courses. I was explaining my reasons for not liking software engineering, which I’ll get to in a moment, and he responded:
“I think following Software Engineering processes is the most important thing”
What? Have we really gotten so abstracted from the end goal that the process becomes most important? What happened to actually developing a good product? Here’s my list of priorities when developing a product:
- Develop a product I’d be proud to have my name on
- Achieve the client’s goals
- Learn new technologies
Notice that there’s no mention of process on that list. I don’t care what process I use, I care about the result. Software Engineering makes people dumb…it encourages them to follow a series of steps without evaluating the appropriateness and applicability of each step along the way.
Too often I see people follow these processes to the letter, sometimes due to their own ignorance, and other times due to the process itself (and management’s enforcement of it) leaving little room for innovation. How can there be innovation when individual programmers aren’t encouraged to think about something as small as the process they follow. Companies should be encouraging programmers to question everything every step of the way. Some of the best business ideas come out of programmers questioning current business paradigms (see countless Silicon Valley startups if you need examples).
A-Teams Don’t Need Software Engineering
Consider the following two groups. Group 1 is full of brilliant, self-starting people who are good communicators. Group 2 has a spectrum of programmers with varying levels of programming and communication skills. They’re both working on an internal tool for a 100 person company that handles money-related tasks, let’s say payroll.
Group 1 Group 1 sits down with management and asks “what does this need to do?” They ask the right questions, and burn through the meeting quickly. Then the team sits down with a whiteboard, draws out what they need the system to do, and talks about security. They copy down their work to the intranet, split up tasks, and go write the system, checking in with each other every once in a while. After the system is done, they test it thoroughly, perhaps write an email to the QA department telling them to really pound the security aspects, and release it.
Group 2 Group 2 performs an initial requirements analysis. They pump out pages and pages of documents with complex diagrams. They review the documents. Then, when they have every item speced out, including class diagrams, functional requirements, and every little detail such that even a monkey can code it from there, the team meets. They split up the work and write it, documenting every tiny thing along the way, and meeting every morning to discuss how they’re doing. After the system is done, they collaborate with QA to produce another large document describing every little detail of what was written, and how to test it, again even a monkey could execute the test plan.
Both plans will produce perfectly good products. However, an extremely talented individual will be incredibly frustrated in Group 2, since he will be pumping out form documents and going over every little detail that won’t make him more productive. On the other side of things, a mediocre programmer will be incredibly frustrated in Group 1, because he’ll be forced to make a decision that he doesn’t have the experience or knowledge to make, and he won’t have the wherewithal to ask for help. He’ll inevitably fall behind and not think to mention it to anyone. The problem with the first situation is that it’s dependent on every programmer being brilliant.
So we have reached the core problem: not all programmers are brilliant (and I’m not saying that I am or am not). Microsoft needs to use SE processes since they need too many programmers to guarantee that each one is brilliant. I’ve seen 100 person companies that are careful enough with who they hire that they are all Group 1s. That’s right: every single one of their employees grasped the big picture, did their jobs well, and were smart enough to ask for help when needed. My personal principle is that if you’re not smart enough to be able to communicate well and produce good code without a strict formal process, I don’t want to be working with you.
Another way to think of this is that the amount you can rely on programmers to make decisions is capped at how much you can rely on the worst programmer (or, as Penelope Trunk, who’s blog I’ve recently become a fan of, puts it: “you should always hire A players because one B player brings everyone down”).
That’s why many software companies spend so much on employee perks — video game consoles, free food, big monitors — because attracting good programmers creates more ideas, better codes, and less managerial bullshit. If the best programmers may make you a million dollars practically overnight, don’t you only want the best?
Let me be clear in saying that I don’t think programmers should hack away all willy nilly. In my education I have found that one of the main caveats of SE is the idea of bringing a set group of processes to the table, and I resent that. Otherwise I have no gripe with the concept of a “process”, but I don’t think one should have any paradigm in mind when starting a project. As an example, I recently gave a presentation on a practicum I took to a large group of SE professors and researchers. I got into a discussion with one of them at the end of the talk, and I mentioned that my team, though technically following Scrum, only met once a week because there were just two of us contributing 12 hours a week each. He replied “then that’s not Scrum”. This is a perfect example of my point: SE in its current form places too much emphasis on process. That’s all I’m saying…perhaps my title is a bit misleading.