Programmer as Market

He's got some good points.

The first startup I worked for had really ugly code... That worked. And for the first couple years, I wrote slightly nicer code that also worked. Eventually, the product matured enough, and had enough customers, that it was time to get serious about clean code. I started adding unit tests and cleaning things up. It was almost impossible to get everyone else on board because they were used to doing things the 'quick' way for so long.

But eventually it became unbearable to continue as we had. The whole company got on board with unit tests, then scrum, and eventually ordered a complete rewrite of the system with clean, maintainable code.

I didn't actually agree with the last bit. I thought incremental changes were best for most of it, and a complete rewrite for other pieces would be the best.

The point is, they started out quick and dirty, launched, made some money, and then started cleaning up. It enabled them to seize the market and hold onto it, despite competitors that came along and threw millions of dollars into developing a competing product.

One size does not fit all.

Pretty much spot on. We are working to employ TDD and CI/CD where I work, and I love this. But at home, on my own personal projects, I just love hacking away. And anything I create just needs to work.

Basically, those that ship win.

... win temporary before they died within 2-3 years because they can't change fast enough due to large legacy code.

Either that or expenses goes up cause you have to pay developers ridiculous salary to work 24/7 (a.k.a don't go home until the bug is fixed).

Same old song. We've seen this once too many until the VHS video is unplayable anymore.

I love optimizing stuff. But if customers don't care about the code being faster, my optimization isn't valuable to them. One thing I can do is work in an area where speed is important at the moment (I say "at the moment", because it changes over time, as people work at it, and there's always Moore's Law, there can also be standard library and VM improvements). Example:

John Carmack's genius for graphics optimization was highly valuable for Doom, because the hardware wasn't powerful enough to do graphics fast enough for people. Gradually, over time, the hardware has improved, and his talent has become less important. But recently, with his work on the iPhone, his genius again becomes crucial, to tweak out every last bit of performance. You can hear his delight that his favourite skills are important again, at 1:50: http://www.youtube.com/watch?v=keu4GiTGQ6M

On the other hand, I'm doing something very complicated at the moment (for me, anyway). To be able to reason about this, I have to separate it into modules that don't interact very much - even if that makes it slower. Because it's not yet clear exactly what the market wants, I'll need to be able to iterate on it, doing different experiments, trial-and-error, backtracking. Therefore it needs to be written in a very simple and straightforward way (no tricks!), so that I can quickly understand and change it. This amounts to "good design" - but it's only because that's what's needed.

It had a ridiculous deadline, but it actually seemed to be going well. The developers (myself included) were more interested in clean, maintainable code than hitting the deadline, so everything was looking really nice. Most of the business logic had been done (and unit tested, of course) and already had another team talking about how they could use it in their code.

Unfortunately, I left the company at that point, so I won't get to see how the rest of the rewrite goes.