Writes large correct programs (2008)

There are many axes of complexity. Routine line of business systems, say an inventory management system for a car dealer, with a proper architecture costs should be additive instead of multiplicative, a certain cost to develop features such as “autocomplete control that draws values from a database row” and a certain cost to deploy that control. Double the number of screens using the same features and you double the cost but it feels like sub linear scaling because for the second tranche of forms you don’t have to redevelop the components and it can go much faster.

That ideal can be attained and you can be in control in application development but often we are not. When you are in control the conventional ideas anout project management apply.

As you get very big you start having new categories of problems, for instance a growing social system will have problem behaviors and you’d wish it was out of scope to control it but no, it is not out of scope.

Then there are projects which have a research component whether it is market research (iterate on ideas quickly) or research to develop a machine learning system or develop the framework for that big application above or radically improved tools.

A compiler book makes some of those problems look more regular like application programs but he project management model for research problems involves a run-break-fix trial of trying one thing and another thing which you will be doing even if you are planning to do something else.

Livingston, in Have fun at work says go along with the practices in the ocean you swim in (play planning poker if you must) but understand you will RBF are two knobs on run-break-fix: (a) how fast you can cycle and (b) the probability distribution of how many cycles it will take. Be gentle in schooling your manager and someday you might run your own team that speaks the language of RBF.

Unit tests put a ratchet in RBF and will be your compass in the darkest days. They enable the transition to routine operation (RBF in operations is the devil’s antipattern!)

They are not a religion. You do not write them because a book told you so, you write them for the same reason a mountain climber wears a rope and if you don’t feel that your tests are muda, waste as they say in Japan.

[flagged]

I’ve worked on and finished some extremely large programs over my years in non-tech enterprise. I’m also an external examiner for CS students, and I’ve regularly talked about how I think the curriculum is outdated. In Denmark where I’m from it’s rare to get a programming application from someone without a related degree. It wasn’t so rare 20 years ago, but I can’t remember when I saw one last. I agree that degrees, and especially CS, doesn’t guarantee that people can code. We use them mostly as a “safety net” in our hiring processes here in my region of the world. Basically you can view hiring the wrong person as the most expensive mistake you can make as a manager, and educations are a sort of risk management. You might think that the “can this person actually program” risk is worst for people who are fresh out of their education but there are a lot of factors which can play into it. Older devs may be set in their ways, maybe even religious about some sort of programming philosophy. On the flip side they will start producing value right away.

Anyway, by far I think the biggest hurdle in our industry right now is pseudo-jobbers like project managers, business process owners, scrum masters, various architects and what not. Not everyone is a waste of time, some of them do excellent work and function as exponential productivity catalysts. The vast majority of them, however, spend so much time engineering the process, architecture, whatever that their teams never ship on time or within budget. In this sense I think “correct programs” is hard to value. Because often the “incorrect large program” that doesn’t scale, will be much more valuable for a business than a “correct program” which never even gets the chance because it took to long to get out there.

Fascinating, what tools are you using to keep track of all that? (Also, are there any interesting practices involved here?)

In my senior design project in college, we were the only team that decided to use version control. I pushed for it, and set up a CVS server, mostly because I was the team lead and thought it was an easy way to feel like I was making a difference on the team. This was around 2005 or so, git didn’t really exist yet, svn was the new kid on the block and cvs was the established player.

I had never used any vcs before and neither had anyone on any team, but man was it worth it. The ability to have one place with the latest code and not emailing zip files around was great, but so was being able to easily roll back to a known good version if we caused an issue, compare changes, etc. By the end of it we all agreed it would have been impossible to do as well as we did if we didn’t do version control.

(This was a cross disciplinary engineering curriculum with ME/CE/CS, ours was slightly more software-heavy than other teams but everyone had some amount of software. Version control wasn’t taught and most teams just didn’t even consider it. It was a very different time from today.)