Nerdlife

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:

1. Develop a product I’d be proud to have my name on
2. Achieve the client’s goals
3. 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.

cmu, software engineering

Fun story: I needed to borrow a friend’s car today. He gave me his set of keys, and said if he found his spare he would swap them. As I was leaving, he ran out. He had found his spare, and tossed them to me. My hands being full, I missed them, and they slid right into the vent behind me. They made a cluck as the hit the bottom of the vent. Then a few seconds later they made another clunk as they flew into the wall below. We both looked at each other and burst out laughing.

The next hour and a half was a parade of ideas and experiments trying to get to the keys. The opening in the vent was about 3 inches thick and twisted around a block of cement such that hands wouldn’t fit in the gap. Throughout the evening ideas were suggested that ranged from a coat hanger with a hook to an electromagnet plugged into a 110-volt outlet (we have a lot of Physicists and Mechanical Engineers in the house…).

We started with an exploratory mission: we taped a flashlight to the top of a webcam, taped the whole thing to a coat hanger, and lowered it into the vent. After a bit of digging we found the keys:

We then spent about an hour sticking every contraption imaginable into the vent trying to grab the keys: magnets, hooks, balls of duct tape. The gap was just too small to maneuver. Finally, everyone had given up as I struggled with the hanger, and I too eventually gave up and went downstairs. That’s when another friend and I decided to try to get into the ceiling of the second floor instead of the floor of the third floor. We took apart a big light fixture, stuck our heads up, and lo and behold, we saw the light from the webcam contraption we still had sticking down the vent. From there it was a hooked wire and some careful reassembly, and we were golden.

Lessons Learned:

• Open vents on the floor are a bad idea
• Either I suck at catching or my friend sucks at throwing
• If your current approach isn’t working, try a completely different one
• When you get your friend’s keys back after he throws them in a vent, don’t scare him by throwing them at him

cmu

jQuery 1.3 just came out, and I must say I’m really looking forward to trying it out. They seem to have made some really great performance improvements, and “live events” will definitely come in handy.

The thing that most caught my eye, however, was the new use of feature detection instead of browser detection. There is an article I read several months back that outlines the concept very well (referring to it as “bug detection”). It’s great to see a framework implement this, as it’s a powerful way to free browser developers from having to leave in their bugs to keep sites working on their browsers (ironic, isn’t it?).

What made me chuckle is looking at the jQuery.support page that outlines what “features” are detected. There are 11 features looked it, and the only time any of them are false are in IE. 8 of them are false in all versions of IE, one is only in IE7, another is in IE 6-8, and the last is in IE 6 and 7 when in Quirks Mode. I always figured that all browsers had compliance issues that required hacks, and IE was just worse, but this makes me wonder: is IE the only one with problems regarding CSS/JS compatibility?