This weekend, I had some minor revelations.
Revelation 1: Watching the fractocumulus clouds roll in over the lake, and talking to Cam about software development, it dawned on me that the default state for software teams is to not produce software. This seems a bit strange, but having worked on various teams in both public and private sectors, I'm convinced it's true. People assume that you can just leave the project in the hands of nerdy software geniuses, and that the final result will be the software solution of their dreams. This is really, really, really not true most of the time. If you do that, you end up with developers who "Go Dark" and end up doing something that nobody understands. And by then there's nothing you can do about it...You've spent heaps of cash and you end up throwing good money after bad. This happens all the time. I often get calls from recruitment agencies that go something like:
BodyShopChicky: "Hi Gordon, I've got a great opportunity for you - can we talk?"
Me: "Yeah, sure"
BodyShopChicky: "Well, there's a 3 month contract with possible extension on a really exciting project with
Me: Uh-huh...
BodyShopChicky: Yeah! Doesn't that sound great! Anyway, they've written all the code, and they just need somebody to help them finish it off, and manage the user acceptance testing and deployment! So, I thought it looked just like the kind of thing you could help them out with?
Me: (sound of mobile being thrown out of car)
Jim McCarthy gets picked on for writing a very depressing book about software development . But the reality is that you need get a team out of this default state before it will be able to ship anything.
At the whack-o-the-diddly-o end of the scale, that's what The Core is all about. On Project Tremble (my current project at TOWER) I'm doing my darndest to build a team that doesn't depend on anything but itself - and one that has functioning dynamics that mean that when things get really horrible and hard (which will happen in a few months) - we'll be able to communicate, get through it without going dark, and ship something great at the end of it all.
(In a few months - Once the schedule really starts to bite, and we start to realise that there's no time, and then we stress out and work late and sulk. Then we end up throwing all our favourite features out the window like pants at a nudist convention if we want to ship anything, ever. This is how it seems to work on most projects.)
Revelation 2: You can fix the fuel system on a 1990 Hyundai Excel with a wine cork and some insulation tape. These things are really worth knowing. Thanks TC.
Revelation 1: Watching the fractocumulus clouds roll in over the lake, and talking to Cam about software development, it dawned on me that the default state for software teams is to not produce software. This seems a bit strange, but having worked on various teams in both public and private sectors, I'm convinced it's true. People assume that you can just leave the project in the hands of nerdy software geniuses, and that the final result will be the software solution of their dreams. This is really, really, really not true most of the time. If you do that, you end up with developers who "Go Dark" and end up doing something that nobody understands. And by then there's nothing you can do about it...You've spent heaps of cash and you end up throwing good money after bad. This happens all the time. I often get calls from recruitment agencies that go something like:
BodyShopChicky: "Hi Gordon, I've got a great opportunity for you - can we talk?"
Me: "Yeah, sure"
BodyShopChicky: "Well, there's a 3 month contract with possible extension on a really exciting project with
Me: Uh-huh...
BodyShopChicky: Yeah! Doesn't that sound great! Anyway, they've written all the code, and they just need somebody to help them finish it off, and manage the user acceptance testing and deployment! So, I thought it looked just like the kind of thing you could help them out with?
Me: (sound of mobile being thrown out of car)
Jim McCarthy gets picked on for writing a very depressing book about software development . But the reality is that you need get a team out of this default state before it will be able to ship anything.
At the whack-o-the-diddly-o end of the scale, that's what The Core is all about. On Project Tremble (my current project at TOWER) I'm doing my darndest to build a team that doesn't depend on anything but itself - and one that has functioning dynamics that mean that when things get really horrible and hard (which will happen in a few months) - we'll be able to communicate, get through it without going dark, and ship something great at the end of it all.
(In a few months - Once the schedule really starts to bite, and we start to realise that there's no time, and then we stress out and work late and sulk. Then we end up throwing all our favourite features out the window like pants at a nudist convention if we want to ship anything, ever. This is how it seems to work on most projects.)
Revelation 2: You can fix the fuel system on a 1990 Hyundai Excel with a wine cork and some insulation tape. These things are really worth knowing. Thanks TC.
Comments
Post a Comment