The Best Code I Ever Wrote (Part 1 of 2)

May 25, 2016

This project was the most pressure-filled thing I ever did yet in many ways it was also the most fun. In the end it was also the best code I ever wrote.

In 1999 or so I was working for a consulting firm working on an application for the US Post Office, and my officemate was assigned to a big new project for a popular magazine. I didn’t really pay much attention at first since I was trying to avoid going postal (USPS was fairly painful to work with). The magazine had boldly promised the previous fall that in one year they would have a fabulous new website that would allow consumers to search their massive consumer product catalog, and especially a database of every make, model, package and feature of most of the world’s automobile manufacturers. It was a bold promise.

I knew it was a big deal since I heard the the magazine had hired another consulting firm who had worked on the project for six months before giving up and telling the magazine that what they wanted to do was impossible. Of course our CEO immediately said we can do it and a team started from scratch. The magazine had all the data in raw form. We (as in the team, not me, I was still postalized) built a database and a data entry system so that an army of 20 people could input and categorize the data.

Read the rest of the article…

How Many People Does It Take To Ship Software?

Apr 5, 2016

There are a million jokes along the line of “How many _____ does it take to screw in a lightbulb?”

Sometimes I laugh at work at how many people are involved in the project I am working on. We have me and one other programmer and 20-30 other people that we can count for a three month or so project. This is after about 6 months of creative approval cycles with an uncountable pile of VP’s; yet changes keep happening despite all the requirements for deciding everything in advance. On top of that it is not too dissimilar to a project done by a different team (though the code is not reusable) that is about to ship.

Why so many people? It’s a mystery why bigger companies have bigger teams to build things that are not so big. I’ve come to the conclusion that the more people you put on a project the more people you need to manage the people you put on the project plus the people needed to manage those people, and so on. “The bigger the team the bigger the team the bigger the team.”

Read the rest of the article…

My Biggest Regret As A Programmer

Apr 4, 2016

A little over 20 years ago I was at a crossroads. My second company was petering out when our 5 years of building Deltagraph for the publisher ended (they wanted to move into the nascent internet space). At that point I had 13 years experience as a programmer but also 9 years or so experience running a company (at the same time).

I no longer wanted to do both. My first company 85-87 not only built a new kind of spreadsheet program but also published it ourselves. I led the company, did all the press interviews, managed the investors, did all the usual business stuff and also was one of the three programmers and the UI designer. After we shipped the product in early 87 I also wound up in the hospital. Trying to be both leader and programmer was simply too much.

So at that point in 1994 I could have gone either into technical management or continued as a programmer. I chose programmer because it was easier. Today I now realize how wrong I was despite all the great stuff I’ve been able to work on and ship over the past 20 years. Going towards the CTO/CIO/VP Engineering route, which was fairly new back then, would have been a much better plan.

Read the rest of the article…

The Myth Of Reusability

Feb 24, 2016

The story always begins with a complaint. Executives complain that software is taking too long and costing too much to build.

Some bright person suggests that money could be saved if software were built to be reusable, thus allowing slightly more expense to result in components that could be leveraged in future development, saving enormous money and effort.

Executives jump on it, each pushing the idea as their answer to cost and performance issues, and wanting to reap the benefits of being seen as proactive.

Read the rest of the article…