Re: OpEd: Programming is not Team Sports

My father in law is a construction engineer. Once I told him that software projects often fail, take to long and/or are way over budget, and that I wished that we used the established engineering practises from his field. He looked at me with very wide eyes and asked me if I seriously believed that "his" embankment dam projects fared any better.

Note that those projects also have significant maintenance costs, often due to less-than-perfect upfront planning and execution.

A commonality between software and civil engineering projects is that planning ahead works well if and only if you know the environment, the problem domain and the requirement very well, and none of them are changing.

I often read programming job ads, and it seems to me that most of them focus greatly on the tools (you need to have 5 years of experience in $language and $framework and $webserver and HTML and CSS and Javascript and 20 years of scrum experience), but mostly ignore the problem domain. I think that is one of the big shortcomings of current "best practices" in the software business.

Explorations into unknown regimes are best done from the bottom up. You can best see that in long-term research projects that first explore the underlying effects before trying to build any devices from them. And any project outside of your domain knowledge is as new to you as a research project is to the scientists investigating it.

So, if you are a software architect who has already built five web browsers, and are now charged building the sixth, taking the waterfall approach might make some sense.

If you have built a browser, a word processor and a web server, building a new compiler is still a research project to you. You could chose your methodolgy accordingly.

Perl 6 - the future is here, just unevenly distributed

Comment on Re: OpEd: Programming is not Team Sports

Replies are listed 'Best First'.
Re^2: OpEd: Programming is not Team Sports by gsiems (Deacon) on May 25, 2012 at 20:35 UTC
++ "...and none of them are changing." This. It seems that it is the rare project that doesn't have changing requirements of some form. When I was in college, lo these many years ago, I did house construction for a while. It was not uncommon to hear "Can you (move\|add\|remove) this (door\|window\|wall\|other)?" in the course of things. As it's a lot easier to (move\|add\|remove) things before you've run the electrical, plumbing, mechanical, or closed up the walls than it is after-- getting the feedback a.s.a.p. is essential to minimizing cost/schedule. Actually, now that I think of it, not everything WAS on the blueprints as the assumption seemed to be that the contractor would figure out the missing details as they went along.	[reply]
Re^3: OpEd: Programming is not Team Sports by Anonymous Monk on May 26, 2012 at 07:17 UTC
Actually, now that I think of it, not everything WAS on the blueprints as the assumption seemed to be that the contractor would figure out the missing details as they went along. They call it "code", it dictates all your options, they have inspectors for it, and you have to know the "code" better than the inspectors, because invariably they'll try to deny permit approval for code violations	[reply]
Re^4: OpEd: Programming is not Team Sports by gsiems (Deacon) on May 28, 2012 at 02:23 UTC
For much of it that is true. However there were a few occassions where no amount of code would account for the missing/overlooked pieces. My favorite was the house where there was no way to run the mechanical to most of the house without adding some additional wall to put it in.	[reply]
Re^2: OpEd: Programming is not Team Sports by DrHyde (Prior) on May 28, 2012 at 11:07 UTC
I actually think it's OK to ignore the problem domain in job ads for almost all programmers. When I was working on systems to support the manufacture of medical devices, and later on systems for support nurses and patients with managing drug use and stuff, I didn't have to know much (or, indeed, anything beyond what any well-educated layman would know) about the problem domain. I was just writing code to gather and process data, and I don't care whether your data is incidents of adverse reactions to a drug or the migration routes of the Greater European Spotted Bat. All I need is to be familiar with the tools that the employer uses, to be intelligent enough to learn the terminology and the basics of the problem domain, and to be confident enough to ask a medic or a bat expert questions when I don't understand the problem, or I think their specifications are vague etc.	[reply]