I discovered the Software Engineering Body of Knowledge today. Full of painful passive voice, but lots of methodology insight if you can survive the atrocious academic writing.
--Nat
Re:Arg!
gnat on 2003-06-30T06:16:24
I had an interesting talk at YAPC with someone who's doing a PhD in software management. He pointed out that software management is trying to do what people management does: obtain consistent quality through well-specified standardized processes. They're trying to get away from relying on brilliant programmers, in other words.I pointed out, and he agreed, that it's yet to be shown to actually work. It's one thing to take anybody and have them operate the deep fryer to produce a McNugget indistinguishable from any other, but software is a completely different kettle of fish. Err, chicken. Err, software. I've worked with fuckwits for whom no amount of process would help, because they just don't have the ability. I've worked with geniuses who can see elegant solutions that no process could come up with.
On a similar note, I'm still quite astonished by the games industry's reliance on last-minute crunches. Every game generally requires a month or more of 18+ hour days from programmers and artists. Every game. You cannot go to the shelves of Best Buy and find a popular computer game that was not created in this fashion.
And yet every software management book you read says this doesn't work. Programmers burn out. You should never ever design a schedule that includes such a crunch. But the games industry breaks this rule every time, and still survives. How the buggery do they do it?
Is it the economics? Does the sheer number of shekels from a successful game mean that even a programmer's cut is enough to make up for the torture? Do they not have any employees over 30? I don't know, but it's mighty curious.
--Nat
Re:Arg!
ziggy on 2003-06-30T13:23:18
Remember that programming is a craft, so forget what the b-school types tell you about management. Look at how carpenters self-manage.He pointed out that software management is trying to do what people management does: obtain consistent quality through well-specified standardized processes.In the olden days, when there was a progression from apprentice to journeyman to carpenter to master carpenter, there was no set pace to advancement. There was no expectation that you deserved a higher status simply because you put another two years into the system. You progressed when you had demonstrated sufficient skill. When you have to find work for someone without the requisite skills, you find some task they can do to help out (and keep them from accidentally maiming themselves).
In some shops I've worked in, the principle of least-damage was in effect: mark out some area of the system where an apprentice can make a contribution without wreaking havoc. This is pretty much where we are today, and where carpentry hit its steady state.
It's nice to dream that you can take a room full of (programmers|carpenters) and simply teach them a process to build a widget. You can to some extent, if the widgets never change. And we all know that programming (and great carpentry) is about making something fresh, new and dynamic, not churning out plugs.
Re:Arg!
chaoticset on 2003-06-30T15:30:42
Hmm...that sort of thing seems to mirror Advogato's trust metric.In the olden days, when there was a progression from apprentice to journeyman to carpenter to master carpenter...Re:Arg!
chromatic on 2003-06-30T16:48:38
But the games industry breaks this rule every time, and still survives. How the buggery do they do it?In one episode of Futurama, Zapp Branigan describes how he defeated a legion of killer androids. All it took was throwing wave after wave of troops at the androids until their internal counters overflowed. The androids shut down.
I'm starting to wonder if the people who think software engineering will work "if it's just done right" even have counters.
Re:Arg!
ziggy on 2003-06-30T20:51:26
In another episode of Futurama, Zapp Branigan attempts to defeat the alien mothership from Omicron Persei 8 by launching wave after wave of ships in an attempt to clog up the alien "Death Ray".Hm. I think I see a pattern here. All problems can be solved if you have an infinite supply of troops to send on suicide missions.
:-) Re:Arg!
chromatic on 2003-06-30T21:04:10
Since it's a formal process, let's give it a formal name. I call it... OUTSOURCING!
-Dom
Re:Doesn't look good
gnat on 2003-06-30T17:07:17
Well duh. That's like Dave Rolsky taking a look at "101 Ways to Torture Bunny Rabbits" and not liking what he sees. Fowler's an XP low-process guy. The SWEBOK is all about process.--Nat
Re:Doesn't look good
autarch on 2003-06-30T17:14:32
While I appreciate being used as an analogy, I'd hope that pretty much anyone who looked at "101 Ways to Torture Bunny Rabbits" would dislike such a thing. I doubt I'm unique in this respect;) Re:Doesn't look good
chromatic on 2003-06-30T18:21:37
If one of the top ten ways to torture a bunny rabbit is "formalize a software engineering process", you've got my vote.
Re:Doesn't look good
Dom2 on 2003-06-30T18:55:09
Oh, I agree. But more than I care about either lots of process or little process, my main complaint from reading about it is that it might be forced onto people as the One True Way. I guess I was alarmed by reading about it being made into some kind of "legal" thing. Not that it'd probably affect me as a non-US citizen.-Dom
P.S. Bunny make good pie!
Re:Doesn't look good
gnat on 2003-06-30T20:31:41
Any country that mandated software be developed according to the formal processes in that document would soon find themselves somewhere behind Albania in the tech race.:-) --Nat
Re:Doesn't look good
ziggy on 2003-06-30T20:43:23
Hmmm. Sounds like a really good book I read not too long ago...Re:Doesn't look good
gnat on 2003-06-30T21:47:32
Yeah, I read that when I started on Perl 6. It's was good, if a little... preachy. Of course, that's the point. But it read like Harry Potter with an agenda :-) --Nat
Re:Doesn't look good
ziggy on 2003-06-30T20:47:21
Well, that's an unfair dismissal of Fowler's dislike of SWEBOK.If you read his commentary (it's very brief), he dislikes the SWEBOK because the field is both too young and too broad to have a formed a generally accepted view of "what works". Plus, it's definition of the "body of knowledge" is needlessly shallow, and excludes things like the Gang of Four.
Re:Doesn't look good
gnat on 2003-06-30T21:53:53
the field is both too young and too broad to have a formed a generally accepted view of "what works"That's nonsense. People have been studying software engineering since the 70s. I agree completely that the idea that there's anything that works in software engineering other than luck is optimistic, but the disciplines that SWEBOK describes (requirements, testing, SCM, etc.) are valid and mature.
The big problem, I think, is that SWEBOK manages to be tedious and pointlessly theoretical about topics that must be, at their heart, practical or else useless.
Then again, I work for O'Reilly and program in Perl, so "practical" may be more of a religion for me than other people
:-) --Nat
