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…

All Code Is Fleeting, Don’t Act Like It’s Forever

Feb 3, 2016

Of all the things I have written in my 34 years of being a programmer, the code I have written that I know is still in use is very limited. Prior to my previous job the only app I know still exists is Deltagraph, which for some reason is still being sold 27 years after I started its main.c, and much of the original code I imagine is still in there as the app hasn’t changed dramatically since we stopped working on it in 1994 or so.

Everything else is gone, replaced, out of business, shut down, superseded or archived for no apparent reason (as if some future archeologist might inquire). I bet most of yours is gone as well. The people who wrote all those banking and insurance systems in the 60’s can say the code has outlived them, if they could. Not all code is malloc() today, free()ed tomorrow of course.

These days I work on iOS apps, and their lifespan is fairly short. At my current job the bean counters hear “mobile” and always respond “expense, you’re just going to rewrite it anyway.”

Read the rest of the article…