Archive for the 'Business' Category
17th Jun 2008
How to incur 3X costs for 1X worth of functionality
A software development lifecycle that does not include design review early in the process is doomed to poor estimates, cost overruns, and a wildly inaccurate schedule.
Why? Let me tell you what just happened to me.
I picked up a task for a project manager because I had some time free and his resources were completely booked. It was a simple feature with a two day estimate and it was already scheduled for release without having gone through design review. Since it was scheduled, it had a code cutoff date. That was last Friday.
The feature was pretty easy to implement. I needed to add a column to a database table, add support for it in our system, create some services (as in SOA) to change this field, and include the field in our web UI. That’s it. One database column with support for it across our system. Not a hard task.
I implemented the feature within the original estimate, I checked my code into our version control system, signed off on the feature, and asked our Database Engineers (DBEs) to include the new column in our test environment. As far as I know, this was the first time a DBE had a chance to review the feature. They put my change on hold while they suggested moving the field to a different table.
The DBE has a good argument for the field being on the other database table. He may be right. The original requirements may have been good but not good enough. But the problem is this review happened after the entire implementation was said and done.
Changing where the column exists represents a 3X cost of the original feature. The first 1X was the original implementation. Should we choose to move the column, I have to undo the original work and then do it all over again for a different table. Even if undoing the original work isn’t a full X of cost, it is still work I have to do that was not part of the original estimate. Redoing all the work on the new table is a full X of additional cost. We’re at least 2X above the estimate.
A 30 minute design review with the appropriate people would have kept the cost to 1X and given us the right solution the first time. Instead, we’ve got a potentially sub-optimal 1X solution or a 3X correct solution. And this was a simple feature. Larger features with more complex requirements would incur significantly higher cost overruns if not properly designed up front.
Design reviews must be an early part of the process, not an afterthought. It is the only way to avoid 3X overruns.
A software development lifecycle that does not include design review early in the process is doomed to poor estimates, cost overruns, and a wildly inaccurate schedule.
Why? Let me tell you what just happened to me.
I picked up a task for a project manager because I had some time free and his resources were completely booked. It was a simple feature with a two day estimate and it was already scheduled for release without having gone through design review. Since it was scheduled, it had a code cutoff date. That was last Friday.
The feature was pretty easy to implement. I needed to add a column to a database table, add support for it in our system, create some services (as in SOA) to change this field, and include the field in our web UI. That’s it. One database column with support for it across our system. Not a hard task.
I implemented the feature within the original estimate, I checked my code into our version control system, signed off on the feature, and asked our Database Engineers (DBEs) to include the new column in our test environment. As far as I know, this was the first time a DBE had a chance to review the feature. They put my change on hold while they suggested moving the field to a different table.
The DBE has a good argument for the field being on the other database table. He may be right. The original requirements may have been good but not good enough. But the problem is this review happened after the entire implementation was said and done.
Changing where the column exists represents a 3X cost of the original feature. The first 1X was the original implementation. Should we choose to move the column, I have to undo the original work and then do it all over again for a different table. Even if undoing the original work isn’t a full X of cost, it is still work I have to do that was not part of the original estimate. Redoing all the work on the new table is a full X of additional cost. We’re at least 2X above the estimate.
A 30 minute design review with the appropriate people would have kept the cost to 1X and given us the right solution the first time. Instead, we’ve got a potentially sub-optimal 1X solution or a 3X correct solution. And this was a simple feature. Larger features with more complex requirements would incur significantly higher cost overruns if not properly designed up front.
Design reviews must be an early part of the process, not an afterthought. It is the only way to avoid 3X overruns.
Posted by Mark Turansky under 
Business, Engineering 
1 Comment »
16th May 2008
How To Kill Productivity, Part I
Here’s a surefire, one-step way to sap your staff of two hours of productivity: 1) poorly schedule two hours worth of meetings!
Peopleware famously dissects productivity among thought workers and persuasively argues that environments conducive to developers getting into the “zone” and feeling the “flow” experience higher productivity than those that aren’t so hospitable. Task switching is considered harmful for those whose jobs require deep concentration, high creativity, and other pure thought stuff.
The meeting scenario in this picture may be mocked up, but it has happened to me in real life as I’m sure it happens in many organizations. It’s the quickest, simplest, easiest way to tack two extra hours onto the cost of those two hours of meetings.
How?
Because, like DeMarco and Lister point out, it can easily take 15-30 minutes just to get into the zone!
When the first alert pops up, I’m usually distracted enough from my task at hand. I need to find out where the meeting room is, maybe grab a cup of coffee, and I’ll probably need to use the restroom. That’s 15 minutes gone.
In between meetings we’re catching up on email. And if it’s a slow email day, we’ll read Slashdot or CNN because it’s just not possible to get deeply into the zone in that short window… just to have another alert pop up in 15 minutes. That’s 30 minutes more down the tubes.
After Meeting #2, we’re again catching up on email or making lunch plans. I don’t care if it’s a slow email day AND you brown-bagged your lunch, you’re still not getting deeply into the zone for meaningful work in this 30 minute window. We’re down a full 75 minutes so far.
And after lunch? Too many of other things can distract us from work: more coffee, restroom, email, chitchat in the hallway, food coma, etc. It’s easily another 30 minutes here to even approach the zone, let alone get into it deeply enough before the next meeting alert pops up…
Poorly planned meetings, spaced out as illustrated, are a guaranteed productivity killer.
Here’s a surefire, one-step way to sap your staff of two hours of productivity: 1) poorly schedule two hours worth of meetings!
Peopleware famously dissects productivity among thought workers and persuasively argues that environments conducive to developers getting into the “zone” and feeling the “flow” experience higher productivity than those that aren’t so hospitable. Task switching is considered harmful for those whose jobs require deep concentration, high creativity, and other pure thought stuff.
The meeting scenario in this picture may be mocked up, but it has happened to me in real life as I’m sure it happens in many organizations. It’s the quickest, simplest, easiest way to tack two extra hours onto the cost of those two hours of meetings.
How?
Because, like DeMarco and Lister point out, it can easily take 15-30 minutes just to get into the zone!
When the first alert pops up, I’m usually distracted enough from my task at hand. I need to find out where the meeting room is, maybe grab a cup of coffee, and I’ll probably need to use the restroom. That’s 15 minutes gone.
In between meetings we’re catching up on email. And if it’s a slow email day, we’ll read Slashdot or CNN because it’s just not possible to get deeply into the zone in that short window… just to have another alert pop up in 15 minutes. That’s 30 minutes more down the tubes.
After Meeting #2, we’re again catching up on email or making lunch plans. I don’t care if it’s a slow email day AND you brown-bagged your lunch, you’re still not getting deeply into the zone for meaningful work in this 30 minute window. We’re down a full 75 minutes so far.
And after lunch? Too many of other things can distract us from work: more coffee, restroom, email, chitchat in the hallway, food coma, etc. It’s easily another 30 minutes here to even approach the zone, let alone get into it deeply enough before the next meeting alert pops up…
Poorly planned meetings, spaced out as illustrated, are a guaranteed productivity killer.
Posted by Mark Turansky under Business 3 Comments »
09th May 2008
The New Yorker publishes an article proving the patent system is broken
The New Yorker has published an article on Nathan Myhrvold’s Intellectual Ventures, a think tank that brainstorms new ideas, patents them, and licenses their subsequent ownership of that new “intellectual property.”
The point of incredulity, for me, came when I read this quote from Bill Gates:
They also came up with this idea to stop hurricanes. Basically, the waves in the ocean have energy, and you use that to lower the temperature differential. I’m not saying it necessarily is going to work. But it’s just an example of something where you go, Wow.
The article talks about Alexander Graham Bell and his genius, and how Myhrvold is inspired by Bell. But Bell didn’t simply think up the telephone and patent it; Bell actually invented the telephone!
Intellectual Ventures files up to 500 patents a year. There are no inventions here, mind you, just ideas. You know the patent system is broken when a company can obtain a government-granted monopoly on an idea like preventing a hurricane and sue the bejeezus out of someone who might actually figure out how to control Mother Nature.
Ideas are cheap. Ideas are easy. It’s the implementation that is hard. The research and successful development of a seemingly impossible idea is worthy of a patent, not the brainstorming for the idea itself. How would you like to solve an impossible problem only to be rewarded with a lawsuit by a troll with a submarine patent who’s put zero work into solving the hard problem? Yeah, that’s what I thought.
The New Yorker has published an article on Nathan Myhrvold’s Intellectual Ventures, a think tank that brainstorms new ideas, patents them, and licenses their subsequent ownership of that new “intellectual property.”
The point of incredulity, for me, came when I read this quote from Bill Gates:
They also came up with this idea to stop hurricanes. Basically, the waves in the ocean have energy, and you use that to lower the temperature differential. I’m not saying it necessarily is going to work. But it’s just an example of something where you go, Wow.
The article talks about Alexander Graham Bell and his genius, and how Myhrvold is inspired by Bell. But Bell didn’t simply think up the telephone and patent it; Bell actually invented the telephone!
Intellectual Ventures files up to 500 patents a year. There are no inventions here, mind you, just ideas. You know the patent system is broken when a company can obtain a government-granted monopoly on an idea like preventing a hurricane and sue the bejeezus out of someone who might actually figure out how to control Mother Nature.
Ideas are cheap. Ideas are easy. It’s the implementation that is hard. The research and successful development of a seemingly impossible idea is worthy of a patent, not the brainstorming for the idea itself. How would you like to solve an impossible problem only to be rewarded with a lawsuit by a troll with a submarine patent who’s put zero work into solving the hard problem? Yeah, that’s what I thought.
Posted by Mark Turansky under Business 5 Comments »
