It's not all bad. I'm pleased to see Ivar Jacobson repeat his call to move beyond "process" to "practices". On the other hand, I'm dismayed to see the SEMAT programme described at it's highest level by these streams: definitions, theory, universals, kernel language, assessments.
Really? Definitions, theory, universals? Are these really the things that the software industry is lacking? The problem here, I think, is that just as at the original "Software Engineering" conferences in the 60's the SEMAT folks have confused the retrospective coherence with which engineering (that is, the mechanical, chemical, electrical, electronic and other flavours) is described with how engineering is actually done.
Similarly, the presence of a spring bow compass in the SEMAT logo worries me. The 60's effort at SE also confused the contingent artefacts produced by engineers (which at the time were actual drawings produced with things like spring bow compasses) with the essence of what engineers do. With this logo SEMAT are associating themselves not just with tools and outputs rather than principles and practices, but with mightily outdated tools. They might as well have put a slide rule in their logo.
It really seems as if an historic mistake is about to be repeated. I need to study SEMAT more, but for now Alistair Cockburn's commentary resonates strongly with me.
He urges that SEMAT does these to things:
I can hope.
- Look at what engineers ‘do’, not what they build.
- Catch up with the state of the art in what is conventionally called engineering.
4 comments:
It's time that reasonable people realize that Software Engineering is merely a metaphor of parts of what we're doing when developing software and delivering it after having it tested. Engineering is not everything we do, just a part of it. There are other parts, but these lack also the same problem of the parts-for-the-whole fallacy. Hope is maybe the last thing we have.
Gush: I think everyone should try and meet and engineer.
Half the time I seriously doubt the wisdom of calling ourselves and our profession "engineering".
The other half the time, when I think there is something in this software engineering lark, I'm proud to point out I'm a third generation engineer: my farther was an engineer, and his farther before him. I know this because they had the rank of Chief Engineer, they wore boiler suits and had oil under their finger nails.
Most of what they did we would consider maitenance. Yet people who talk about software engineering always seem to focus on the initial building.
Software, like ships, might spend a year or two under construction, on the slip way. Once its launched thats when the real engineering starts: fitting out, operating, over hauling, modifying, and making money.
I see it as a reactionary response against the big-P Pragmatism that's been informing a lot of work in the last few years. Well-meaning as they may be, there's a tendency in what I've seen in the SEMAT movement to invoke "objective", "universal", "prescriptive" formulae.
The academic and industrial cultures in which many of these folks seem to work doesn't permit a standard of "it always depends"—but the things any agile practitioner does are all designed for and framed on exactly that worldview.
I can't see it ending well, in any case.
@Bill: a reactionary response, indeed. I wish the industry didn't have this tendency to lurch from one extreme of misapplication of what would be good ideas in moderation, to another. And back again. And again.
@Allan: making money, yes. I think what dismays me most about the vast majority of the "software engineering" material I come across is that it manages to firmly ignore economics. And by ignoring economics it ignores compromise, and making trade-offs, and dealing with contingencies, and all that other stuff that I for one think characterize an engineering solution.
Post a Comment