Turning Skills into Money
September 21, 2009 at 1:34 pm 3 comments
Kent Beck, in his blog Three Rivers Institute » Blog Archive » Turning Skills into Money, comes up an interesting contrast to the previous article on “Critical thinking.” Basically, economics favors ignorance and high turnover in the software services industry. “Just enough senior people need to remain to provide the leadership necessary to keep projects from failing. More than that is a burden.” How do we improve an industry that rewards a lack of knowledge?
Advertisement
Entry filed under: Uncategorized. Tags: .
1.
Erik Engbrecht | September 21, 2009 at 10:22 pm
I think lack of knowledge is quite clearly being severely punished, it’s just that it’s the customer’s lack of knowledge, not the service provider’s. The industry is being rewarded for treating its customers like hapless marks. This is a common situation in industries where time & material billing are combined with a subject matter that is largely foreign to the customer.
Therefore, the solution is to educate the customer.
2.
Mark Miller | September 23, 2009 at 1:19 am
I’ve wished in my heart of hearts for years that this would happen. There’s a kind of punishment that the service providers suffer as well, as a result of the customers’ ignorance. Many developers care about design to a certain extent. Those who work for service Co.’s have to put up with the idea that sometimes they have to produce a mess to “get it done”. They aren’t given enough time to produce a good design.
Almost all the projects I worked on were fixed bid. I cringed at what I was doing sometimes, but I just gutted it out to get the thing done. I had to go back to my old designs and deal with them during maintenance. Depending on how rushed we were to get the thing off the ground in the first place, it could be rough. Sometimes I pitied whoever had to come after me.
After my first year of working on software like this I realized that a big part of the problem was the customer’s conception of software. They literally didn’t care how the software was constructed. It could’ve been written in the most horrid spaghetti code and it would’ve made no difference to them. Their conception of what was supposed to happen was “We agree on a spec. You make the computer do that. I don’t care how, because I don’t have the first clue of how you do it.” They never looked at the end result: the code we actually wrote. All they saw was the working program. It took me a couple years longer to get a grasp of the aspects of the project life cycle that were driving this dysfunction. I don’t have a solution for it, but I could see the problem more clearly.
There were exceptions. If I worked on non-revenue-generating internal projects, those tended to go very well as far as design went, mainly because there wasn’t much of a deadline, and no budget to pay attention to. A few projects I worked on for customers had pretty good designs. They were the exception, not the rule.
Customers always seemed willing to pay for whatever it took us to fix bugs and add features to the mess (on a T&M basis), despite the fact that I knew it was taking us longer to do because of the bad design. It really frustrated me. I felt like if I could have a sit-down conversation with the customer I would tell them this so they would at least get the idea that design matters and they should review the end product, source code and all. I never got the chance.
The question is how to get customers educated? I don’t know if anything has changed in this regard, but project managers could literally come from any profession. In one service Co. I worked at 8 years ago my project manager had a background as a paralegal. The same applied to the customer liaisons we dealt with. They did not all come through the same schooling or work background. So getting the people who are driving projects educated is a major challenge that I don’t think anybody has even begun to tackle.
3.
Mark Miller | September 23, 2009 at 1:38 am
BTW, I liked the article. I think it clearly spells out what’s going on at some service Co’s, anyway. The comments after it are illuminating as well. Having different cost structures seems to drive different behaviors WRT skill levels that are promoted in this type of business. I left a comment saying that I used to advocate for a time & materials (T&M) model, because I was always in the business of writing custom software. So each piece of software was a new experience, one that each developer had to learn about in order to complete. And the only way we found to do this was to start getting into the code (after doing some initial conceptual design work) and see what worked and what didn’t, and make decisions from there. Like I said in my comment to Erik, almost all the projects I worked on were fixed bid, which meant that after a requirements and design spec. had been written we would agree with the customer on a fixed budget for the project before we had written a line of code. This used to make me sweat bullets, because this meant each of us had to come up with an estimate of how long it would take us to complete each part of a system. I always felt like “I don’t know how long it’s going to take me to do any of this.” It felt like a big unknown. It’s a common experience with young developers. Maybe this is true for more experienced developers, too, though I felt more comfortable with estimating as I gained more work experience. I felt much more comfortable if I was able to work on the code for a while and THEN give an estimate.
Anyway, apparently the T&M model tends to push out skilled talent, whereas the fixed bid model tends to make skilled people more valuable, because there’s no slack. The company can’t afford unskilled workers because they’ll miss the budget by a mile. I say “by a mile”, because in my experience the project teams I worked with (with fixed bid projects) also frequently overshot budgets and schedules, but maybe not by as much.
There were some other cost models proposed in the comments, though it seemed like they hadn’t been tried.