Snagged from Daring Fireball: Adobe edits the development cycle

Probably the most effective thing we did was institute per-engineer bug limits: if any engineer’s bug count passes 20, they have to stop working on features and fix bugs instead. The basic idea is that we keep the bug count low as we go so that we can send out usable versions to alpha testers earlier in the cycle and we don’t have the bugalanch at the end.

The goal is to always have the product in a state where we could say “pencils down. You have x weeks to fix the remaining bugs and ship it”. The milestones are primarily measurement points, with the acceptance metric being quality instead of something like “all features in” or “UI Frozen”.

There are two things I’ve seen or heard of which I believe is a really nice idea, software management wise. This is one of them.

The other is the idea of the weekly team meeting. I know most people hate team meetings–and they can become obnoxious if you have a large team. But I’ve been on projects where we never held meetings–and on one project I couldn’t have picked out half of my teammates in a police lineup if I had a gun pointed at my head.

On the other hand, I think team meetings should be limited to one hour a week. Stand-ups (where everyone is supposed to meet for 15 minutes, like the huddle before a game play in football) strike me as a completely useless exercise that only makes managers feel good that they’re “doing something”, and team meetings that last more than an hour or meet more than once a week are also equally a waste of time.

Lots and lots of column space has been devoted to the proper techniques for doing software management and software engineering.

I have one. It’s a simple one–but strangly one that I haven’t seen honored on any project I’ve worked on in a large colaborative environment, much to the detrement of the team. That rule of thumb is this:

If you are using an IDE, and you cannot simply open up the project file for the project you are working on and press “debug”, then your build process and project file is broken.

Now I’ve heard all sorts of objections to this rule of thumb on the projects I’ve worked on. “Oh, my project contains a bunch of DLLs which require special code in order to be hooked into the OS.” (Uh, DllRegisterServer, anyone? And the Visual C++ debugger will automatically run DllRegisterServer for you when you hit the debug button.) “Oh, my project is scattered across a whole bunch of different projects.” Then your build process is broken, since every modern IDE I’ve encountered can handle multiple projects. “Oh, I’m building something specialized like a device driver.” Okay, in that case I can see your point: the IDE tools may not be quite up to snuff. And one project I’m working on hooks the OS at a very low level–but really, how many people are working on low-level back-door OS hooking code? And shouldn’t that be segregated in such a way so that the majority if your code can operate even without the hooks?

By and large the biggest problems I’ve encountered which prevent a newbie from opening up a project and pressing the “debug” button is because the other developers just don’t care enough to make the build process simple. They cannot be bothered to look up how the IDE they’re using works; they cannot be bothered to read the documentation that describes how COM DLLs are loaded–and so they create these humongous piles of junk trying to solve a problem that was already solved with a more elegant–and IDE friendly–technique.

Fundamentally, if you cannot just open the IDE and hit “debug”, your project is broken. And if you cannot figure out how to make it so you can just hit the “debug” button, perhaps you need to spend some time figuring out why, rather than creating all sorts of weird workarounds because you’re too lazy to RTF (IDE) M.

Q: All the cool kids are using Java 5.0 or later. Why are you using Java 1.4?
A: Because v1.4 runs on MacOS X v10.3, which means if you want your Java code to run on 10.3, you need to use Java 1.4.2. And because I’m a bit of a simplicity person: while generics, the new for(;;) loop syntax, and auto-boxing is cool (and nice and useful and all that), they don’t really matter to me all that much.

One of the reasons why such compiler-time tools are useful to many programmers (as I discover time and time to my chagrin where I work) is that many are too lazy to actually test their damned code by at least stepping through the newly written stuff before checking it in. So having auto-boxing and typesafe enums allows more stuff to be found at compile time because some programmers don’t bother to check it at run-time is a good thing: it just takes one idiot programmer who doesn’t check his work to ruin your whole day.

Me; I single-step through my code as I write it. In my opinion, if your project requires more steps to debug than opening up the project file in your IDE and pressing the “debug” button, the build process for your project is hopelessly broken and a defect should be filed immediately. So unless it means there is something subtle going on (like in the CIMMail project, natch, which causes one transaction in a thousand to screw up), or unless you misunderstood the specifications, your code will be relatively solid and reliable the first time around.

So I’m thinking of switching jobs because I hate the commute. Of course the best time to think about switching jobs is when you don’t need to nor really have to–in my case I’d be perfectly happy staying put for another 5 years, but honestly the drive is killing me. So I’m “exploring my options.”

One “exploration” involved talking to a head-hunter who then sent me to a site to take a stupid on-line test.

I get it: it’s a great screening mechanism to filter out the bozos who claim years of Java or SQL or C++ but who wouldn’t know the difference between a class and a struct or a select verses an update–and lord knows I’ve interviewed enough people where I work who claimed expert knowledge but who couldn’t write a function call to save his life.

But ohmygod that was the worst test-taking experience I’ve ever had. Perhaps I’m just old: it’s the first test I’ve ever taken on-line. But I like being able to go back and check my answers, and I like being able to run through the test out of order so I can spend extra time on the hard questions. The whole “you have three minutes and if you don’t hit the OK button we’re taking you to the next question” combined with the “hit the back button at your own dooooooom!!!” thing drove me bats. And that says nothing about staring at tables full of tiny tiny little text and a SQL statement and the question “how many values will this return? 8? 9? 11? 13?”

I have a headache.