Restructuring

It often seems like a good idea to throw out all your code and start again; especially when you just took over someone else's code and it's now your job to maintain it. The reason it seems like such a good idea is that the problem space sounds so simple... but the code looks so complicated. So you throw it away, and write it from scratch. That's when you realize why the old code was so complicated: there were lots of special cases for all the weird bits that you didn't realize were part of the problem space in the first place. So your rewrite gets big and complex too. If you're very smart, at least it eventually gets to be better than the original; but even then, it takes a long time to do. And if you're unlucky, your rewrite is merely bigger and slower, not better.

Companies are the same. Company processes are designed and encoded (eg. through forms or software systems) over a long period of time, and they cover lots of weird special cases. When you look at the problem space, it sounds so simple, and you wonder why the solution has to be so complicated. So you throw it away and start from scratch, redesigning a bunch of things to better align with your way of seeing the world. But it means you've lost the benefit of all the tweaking you've been through over the last few years; perhaps your overall model is better, but the surface details are lumpy, inefficient, and downright wrong at first. If you're very smart, hopefully it eventually gets to be better than the original; but even then, it takes a long time. And if you're unlucky, your redesigned company is merely bigger and slower, not better.

With any great redesign, you have to be constantly on the lookout for mistakes. No new design or implementation is perfect right from the start. The biggest danger is to assume that it is, and find out only very late that you're wrong. (That way is called the "waterfall method," and it's very inefficient.)

Looking for a job in Toronto?

Speaking of restructuring...

NITI has a job posting for a QA Manager in Markham, Ontario. If the corporate version of the job description looks uninspiring, see instead my version: Evil Death Ray. Actually, Evil Death Ray is a "QA Person", while the new job is "QA Manager." But the idea is the same, only more so.

You'd be working on testing our award-winning Nitix distribution of Linux, the only one that has ever been successful in servers for small business. Yes, we are open source friendly. And you'd get to play with our super fun, room-filling Project Death Ray test cluster. As well as annoying me, one of the shoddy developers whose code you'd be breaking.