Article by Tom DeMarco Another link in case that doesn't work. I'm not a veteran programming wise but it seems like he throws SE under a bus completely. I understand, from the article, that not all projects (commercial or otherwise) need a fine level of control. But he seems to apply his theory to 90% if not all projects. Since my inexperience is going to hinder any critique I have of this. I turn this to you all. Is this article on point? Or is he blowing hot air? Or something in-between?

From a quick gloss over it, I think he merely argues measuring software projects with some absolute scale won't work. Software building isn't a well quantified endeavour like, say, building a bridge (to some extent) or more conventionally, assembly line work. If you like, I think Joel Spolsky discusses this from another angle in his article Evidence Based Scheduling. Also I find Poppediecks' book has relevance here. It's a quick and good read if you can get a hold of it. The title may lead a bit astray, it's not a lean/XP/agile gospel or somesuch.

In wider context, I think, these issues are discussed in systems thinking as long as it pertains to project management. This connection probably seem a bit arbitrary, but it's there. Unfortunately I'm not qualified to elaborate this statement.

<edit...
Finding a scale to measure software is difficult. Against which factors? Which kind of a scale for these factors if found? Are some factors universal? Can these factors reduced to well quantified figures (like numbers) that have a meaning in some well enough defined context? Etc.

So, not a death of software engineering. It's still engineering (if done properly), but perhaps different kind of engineering than is traditionally considered to be an engineering discipline (whatever that means then).

Quote: Original post by Naurava kulkuri
Finding a scale to measure software is difficult. Against which factors? Which kind of a scale for these factors if found? Are some factors universal? Can these factors reduced to well quantified figures (like numbers) that have a meaning in some well enough defined context? Etc.

Fully agree. In my opinion the biggest mistake people make when managing software projects is to assume that it's like any manufactured product; x pieces + y people = z time.

The problem with that is that in software, nothing is duplicated like in manufacturing. If you are duplicating things you are doing it wrong. So that leaves us with something in which every piece developed should be unique and new, and therefore it becomes very difficult to predict when they will be complete.

Another problem is that for some reason, people seem to think that everything is infinitely mutable in software. I guess because they don't see an actual physical object they think that changes are trivial. In every company I've worked, we've always been given requests that would seem absurd if we were building a physical object. I liken it to constructing a building with elevators that go up and down, getting 80% of the way done, and then being told that the elevators should actually move side to side instead.

I once had a manager tell me that the wonderful thing about software is "that it's just bits, it doesn't have to follow any rules of physics, we can do whatever we want with it by arranging the bits in a different order". Rather than explain to him the ins and outs of network topology, the speed of light, and the laws of thermodynamics, I ended up finding a better job.


Anyway, most engineering disciplines have had centuries to mature. Software's only been around for a few decades. There's a lot of maturity that needs to be attained before software engineering comes of age.

Quote: Original post by Mithrandir
I liken it to constructing a building with elevators that go up and down, getting 80% of the way done, and then being told that the elevators should actually move side to side instead.

A real clincher! This just became my new analogue of choice. :-)

Quote: Original post by Mithrandir
I once had a manager tell me that the wonderful thing about software is "that it's just bits, it doesn't have to follow any rules of physics, we can do whatever we want with it by arranging the bits in a different order". Rather than explain to him the ins and outs of network topology, the speed of light, and the laws of thermodynamics, I ended up finding a better job.

I think you're being too hard on him. Sure there are rules that dictate how software can be created, evolved and maintained, but still, it's significantly more flexible than most other enginneering fields that deal with physical objects...

Quote: Original post by mikeman

Quote: Original post by Mithrandir
I once had a manager tell me that the wonderful thing about software is "that it's just bits, it doesn't have to follow any rules of physics, we can do whatever we want with it by arranging the bits in a different order". Rather than explain to him the ins and outs of network topology, the speed of light, and the laws of thermodynamics, I ended up finding a better job.

I think you're being too hard on him. Sure there are rules that dictate how software can be created, evolved and maintained, but still, it's significantly more flexible than most other enginneering fields that deal with physical objects...

That wasn't the only straw mind you. He made a great many questionable decisions that all culminated in my leaving.


Now you're right, software is inherently more flexible... but software engineering shouldn't rely on that fact as part of its daily routine, which most software projects seem to do. I'm not saying you need to do the waterfall thing and design every little thing up front, but at the very least there shouldn't be the expectation that up to 80% of the entire application can change even if 80% of it is already done.

That's what always annoyed me about "agile" and "extreme" programming. Rather than attempt to come up with a coherent vision and design up front, people just acquiesced to the notion that design should be inherently mutable and that justifies throwing code together as fast and thoughtlessly as possible (and as long as you've got unit tests everything will work out in the end. Oh and unicorns and rainbows too).

My current place of employ is recovering from agilitis. My team is building a completely new product to replace a failed agile product that was in development for 7 years and never made a delivery. They've got more lines of code for unit tests than our product will clock in at total when it's done. The weird thing is, the agile method took on a life of its own. So many people were off doing so many things, and so many things were changing so often that it's now considered a total loss because no one can understand why it's doing what it's doing (but at least the tests verify that it works!! sort of). The unit tests that verify the product works have taken on sort of a biological evolution; in that the things they test for no longer even match what the functions do anymore (but they pass because they don't test for the proper range on inputs, so the tests work for the limited subset of original input data).

Luckily that whole method of thinking seems to be just a fad and is now starting to fade away. I really was getting sick of agile-blinded managers thinking they can use that method to avoid having to actually design software.

Quote: Original post by Mithrandir
That's what always annoyed me about "agile" and "extreme" programming. Rather than attempt to come up with a coherent vision and design up front, people just acquiesced to the notion that design should be inherently mutable and that justifies throwing code together as fast and thoughtlessly as possible (and as long as you've got unit tests everything will work out in the end. Oh and unicorns and rainbows too).

I think you would like the Poppendieck book (I don't know if the new one is better or even handling the same matters). They have an example from car prototype design, for instance, in which they show that it is not a rigorous waterfall-like thingy, but a creative process resembling software design. Getting the moulds or some design decisions wrong costs a lot of money and is something to be avoided, but still the designers need to make decisions and try new things.

You may not agree with all there is written in it, I didn't, but it's thought provoking for sure.

Quote: Original post by Mithrandir
My current place of employ is recovering from agilitis.

From what you describe, Ron, it sounds more like the software team is poorly managed instead of a failing of the process. Or, there was extreme resistance in the dev culture (I *KNOW* you're a troublemaker). Or, and least likely, the product was ill suited to the process.

Agile will fail if handled poorly, if there is no buy in from the devs.

Another possibility is that they just really went overboard not knowing what they were doing, a la the silver bullet approach. My employer does that, too.

Quote: from the article
An Unsettling Analogy
Imagine you’re trying to control a teen-ager’s upbringing. The very idea of con-trolling your child ought to make you at least a little bit queasy. Yet the stakes for control couldn’t be higher. If you fail in your task, fail utterly, lives can be ruined. So, it’s absolutely essential that you not lose your grip entirely. You’re like a fencer who’s learning to hold his sword as though it were a bird: too tight and the bird will be injured; too loose and it will fly away.

So, he's using falconry as a metaphor for fencing which is a metaphor for raising a child which is a metaphor for software project management? [grin]

Quote: Original post by ChaosEngine

Quote: from the article
An Unsettling Analogy
Imagine you’re trying to control a teen-ager’s upbringing. The very idea of con-trolling your child ought to make you at least a little bit queasy. Yet the stakes for control couldn’t be higher. If you fail in your task, fail utterly, lives can be ruined. So, it’s absolutely essential that you not lose your grip entirely. You’re like a fencer who’s learning to hold his sword as though it were a bird: too tight and the bird will be injured; too loose and it will fly away.

So, he's using falconry as a metaphor for fencing which is a metaphor for raising a child which is a metaphor for software project management? [grin]

Indeed, that is an absolutely disgusting paragraph.