"Why do all Engineers Suck?"

The other day I was browsing digg's "upcomming" and found this, where a project manager for some software project at a "very large internet company [in] Palo Alto" complains that all of the projects she is involved in seem to be buggy, miss deadlines, and miss the launch date. She seems to think reason for this is that "...all Engineers Suck". She then proceeds to wonder: "Why are there any bugs in the first place. Are they engineers or not?". Nowhere in her rant does she seem to consider that she might be part of the problem. Just like any other job, its completely useless to blame the job for being hard.

In my best guess she is fresh out of MBA school, arrogant, and (un)blissfully unaware of the challenges of technical projects, esp. software projects. Clearly the technical part must be the easy part; MBA school was just sooo hard.

In the end she questions whether she should move her career outside of technology. Clearly my opinion is yes.

But regardless of the ridiculousness of this misguided young project manager, the underlying question is important. What should management know about how to manage software projects? Software is hard to do right. Why else would the biggest names in software have had problems meeting release dates and going over budget? The reason its so hard is that it is full of uncertainty. Virtually all non-trivial software projects take a large amount of experience and skill to make any kind of relevant predictions about time & resource requirements. Managing that risk requires being in good communication and on good terms with the engineers who know enough about the project to know where the risk is.

So how do you deal with, or reduce the risk? The famous Joel Spolsky of Joel on Software claims that the way around this is via micromanaging schedules down to the day (weeks are too large). I disagree. I agree when he says "..software developers are building things that they've never built before. If they had, they'd just sell you another copy of the CD-ROM.". But I would use that very sentiment to argue that this is why you cannot plan down to the day.

I do not believe that completely upfront design works for most teams. Its just not possible to conceive of all of the possibilities up front. Except for extremely experienced developers, we learn as we go. The time necessary to own the concepts behind the problems you are working on is unpredictable.

Another problem is the process for making design decisions. When a developer is designing a subsystem in a project, many many design decisions have to be made. So many that sometimes that its hard to decide where to spend time, and where to just do the most obvious thing. Often decisions expected to be inconsequential become problems down the line. It is then necessary to go back and redesign to correct for the unforeseen issues, which can eat up lots of resources, but *must* be done lest the project become a mess of hacks. And thats just the beginning of the challenges developers face.

So I argue this: You have to put the management of the risk in the hands of an engineer. The manager of a project, where possible needs to be hands on. Specifically someone who is actually doing some of the work in the project coding and designing. No one can understand the trade-offs involved in what needs to be done right and what needs to be right-now without being directly involved in the development. Anyone who tries to do this from outside will cause bad design decisions, other reductions in quality, and discontent in the engineers. And, let me tell you, discontented engineers are a *very* bad thing.

So my advice is this: find a respected leader within the team and direct the team through the leader because, for the most part, when it comes to engineering, engineers respect only engineers.

(ADL & C++) == sucks

So I was recently writing some code in C++ and came across yet another of C++'s many quirks/pitfalls. This one is called ADL. Argument dependent lookup.

What that means is C++ will sometimes search non-explicitly available namespaces for symbols. I hope you are scratching your head right now. Yes, the whole point of namespaces is to prevent the possibility of namespace collisions. And yes, this "feature" prevents you from trusting namespaces.

From wikipedia here is an example of how this can screw you over:

    std::swap(a, b);

...may or may not be the same as the behavior of...

    using std::swap;
    swap(a, b);

...if in the vastness headers your project includes there is a function called swap, under the "right" conditions it may be used instead of the one you expect.

Yes, there are situations where it is useful. But it pisses me off none-the-less. If you are interested, read the wiki article here:

http://en.wikipedia.org/wiki/Argument_dependent_name_lookup

Sometimes I really hate C++. I hope D will be my savior.

Interactive Video Lectures

So I've started watching video lectures on MIT's OpenCourceWare (OCW) site. Its really nice to be able to watch a lecture when you are in the mood to pay attention. Its likewise great to be able to pause the lecture when you are interrupted or if you need a break for any reason. The only thing missing it seems to me is the ability to ask questions.

So I thought about it and it seems that it wouldnt be to hard to correct that. If the lecture videos were flash based, it would be great to be able to hit a 'question' button at a certain point in the lecture and either type in or record your own question. The lecturer would get a notification (via email or otherwise) that a question had been entered and he could record an answer that would be either inserted into the video of the lecture automatically or shown as optional content when students reached that part of the lecture.

There's lots of great additional things that you could do around this idea, like have Atom or RSS feeds for students to see new questions&answers that have been added. Multiple similar questions could be answered at once, and the quality of the lecture would go up as the lecturer would have the most appropriate feed back and an easy way to reintegrate the feedback into the already completed lecture.