Comments on: Culture of Failure http://blogs.snowmoonsoftware.com/editorial/culture-of-failure/ Connecting ideas to code Mon, 21 Apr 2008 02:21:49 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: link[rel=’developer’] » The Art of the Exit http://blogs.snowmoonsoftware.com/editorial/culture-of-failure/comment-page-1/#comment-39 link[rel=’developer’] » The Art of the Exit Fri, 31 Aug 2007 01:07:07 +0000 http://blogs.snowmoonsoftware.com/editorial/culture-of-failure/#comment-39 [...] on August 30th, 2007 by Jeff So you’re discovered that the company you work for has a culture of failure, and there’s no light at the end of the tunnel. You’ve finally realized that [...] [...] on August 30th, 2007 by Jeff So you’re discovered that the company you work for has a culture of failure, and there’s no light at the end of the tunnel. You’ve finally realized that [...]

]]> By: Mike http://blogs.snowmoonsoftware.com/editorial/culture-of-failure/comment-page-1/#comment-38 Mike Wed, 29 Aug 2007 14:01:53 +0000 http://blogs.snowmoonsoftware.com/editorial/culture-of-failure/#comment-38 Hi Jeff, Great article! I tend to use a pyramid, with the axis of features (scope), time, and quality. I tend to lump the current team, their abilities and their tools together and just call it the team. The team is able to slice a plane through the pyramid. The area they can cover is their combined abilities (tools, talent, and cohesiveness). Management can tilt the slice anyway they want, but the area of the intersection cannot be changed. But that's just the way I think of the work pyramid. Good ideas! Take care, mike Hi Jeff,

Great article! I tend to use a pyramid, with the axis of features (scope), time, and quality. I tend to lump the current team, their abilities and their tools together and just call it the team. The team is able to slice a plane through the pyramid. The area they can cover is their combined abilities (tools, talent, and cohesiveness).

Management can tilt the slice anyway they want, but the area of the intersection cannot be changed. But that’s just the way I think of the work pyramid.

Good ideas!

Take care,
mike

]]> By: Jeff http://blogs.snowmoonsoftware.com/editorial/culture-of-failure/comment-page-1/#comment-37 Jeff Mon, 27 Aug 2007 01:47:42 +0000 http://blogs.snowmoonsoftware.com/editorial/culture-of-failure/#comment-37 Thanks for the comment, Rod. You make some good points but I need to point out that while Sales wants more Features in Less TIme but at a high Quality; the only way that cam be accomplished is by adding Resources. I've also worked with many developers who just want a paycheck, and only care as much as they have to. These people are the bane of good engineers everywhere. The Bullet Hole methodology you propose for creating a roadmap is solved, at most companies by <a href="http://en.wikipedia.org/wiki/Random_walk" rel="nofollow">Drunkard's Walk</a> because the <a href="http://en.wikipedia.org/wiki/Travelling_salesman_problem" rel="nofollow">Travelling Salesman</a> is just too damn <b>NP-Hard</b>!. Thanks for the comment, Rod. You make some good points but I need to point out that while Sales wants more Features in Less TIme but at a high Quality; the only way that cam be accomplished is by adding Resources.

I’ve also worked with many developers who just want a paycheck, and only care as much as they have to. These people are the bane of good engineers everywhere.

The Bullet Hole methodology you propose for creating a roadmap is solved, at most companies by Drunkard’s Walk because the Travelling Salesman is just too damn NP-Hard!.

]]> By: Rod http://blogs.snowmoonsoftware.com/editorial/culture-of-failure/comment-page-1/#comment-36 Rod Fri, 24 Aug 2007 20:07:51 +0000 http://blogs.snowmoonsoftware.com/editorial/culture-of-failure/#comment-36 Great article Jeff. I’ve been thinking about this lately since you mentioned it and I have one more thing to add to the list and that is the internal battleground that I perceive as existing within a company over the triangle. For my example I’m going to deviate slightly from your model and use the Triangle of Features, Time, and Quality. The internal battle I’m referring to is waged between groups in a company and even between management and their staff. It is my opinion that developers leans towards Features and Quality. Most want to develop good code by taking the correct steps towards fixing a broken system and then implement interesting new features on top of a better off code base. However if we move over to Sales you’ll see that they’d rather have more Features in less Time. These two forces will always be in conflict with each other and that’s where we come up with the schedule. I don’t argue that schedules are a bad thing, heck if developers don’t stop to say it’s in a state we can ship and be happy we’d never ship anything because there’s always more work (so long as there’s a roadmap.. but I’ll get to this in a second.) The big problem in this conflict is in which direction is it skewed and on which side is the management in charge of engineering. When the engineering managers are on the side of Quality, they will fight tooth and nail against any unreasonable release dates and rather push them out than insult a costumer with poor quality. When the managers are fighting for Sales, they have now become the person who looks for a way to sweep something under the rug and to ‘bring things in’. Often you hear the phrase “Is it really going to take that long,” “Do we really need to do that,” “Customers won’t do that,” “That isn’t a typical use case,” or even worse, an admission of failure, “We’ll fix that in a service release.” We you hear these phrases from your managers and you’re in engineering, you’ve just been set up for failure. Management in engineering should /never/ be given incentives to ship on time above having a product of the highest quality and they should be willing to fight for this. Now on a tangent, I’ve thought a bit lately about what a Roadmap means. I’m sure this has come to many already but a new developer must pause to think about why it is called a Roadmap. A Roadmap isn’t just a list of things you need to do or plan to do. It is that list of things in a two dimensional list, your map, and their distance from each other represents how related they are in the code and feature set. Now, often companies elicit feedback from their customers which will prioritize these features. If you were to superimpose this onto your map by using circles and those with a higher priority are darker and have a larger radius, you can start to see what customers are calling for and what all the features in the vicinity affected by the demands are. The goal of product management, as I see it now given what I view a roadmap as, is to play the traveling salesman. They should look at the map and start around the highest priority item and then figure out what is the shortest distance they need to travel to get all of these things implemented? By minimizing distance he will save development time because this helps to group like features together which means less context switching on the part of development. There is no later ‘coming’ back to figure out how something worked again. This reduction of context switching will also lead to better quality since all the gotchas a developer discovered while in the code the first time will still be fresh in their mind as they move to the next related feature. Another nice thing about this view of the Roadmap is you can see the hot areas and when you implement all the things in a hot area you haven’t just released a feature, you’ve released a feature set which will more serve the customer in what they were trying to to. So perhaps an example of what I’m saying here is a feature to send messages to customers is in high demand. A related feature around this is that you have a notification system in your product but it really isn’t that good, maybe bug ridden or just flakey. These two would be on the roadmap and somewhat close together and while customers are not calling for fixing your current notification system the overlap of the demand for messaging will dragged notification in as a necessity. Anyways, this is my brain dump for now. I think I might have exceeded my quota for thinking today. ~ Rod Great article Jeff. I’ve been thinking about this lately since you mentioned it and I have one more thing to add to the list and that is the internal battleground that I perceive as existing within a company over the triangle. For my example I’m going to deviate slightly from your model and use the Triangle of Features, Time, and Quality.
The internal battle I’m referring to is waged between groups in a company and even between management and their staff. It is my opinion that developers leans towards Features and Quality. Most want to develop good code by taking the correct steps towards fixing a broken system and then implement interesting new features on top of a better off code base. However if we move over to Sales you’ll see that they’d rather have more Features in less Time. These two forces will always be in conflict with each other and that’s where we come up with the schedule. I don’t argue that schedules are a bad thing, heck if developers don’t stop to say it’s in a state we can ship and be happy we’d never ship anything because there’s always more work (so long as there’s a roadmap.. but I’ll get to this in a second.) The big problem in this conflict is in which direction is it skewed and on which side is the management in charge of engineering. When the engineering managers are on the side of Quality, they will fight tooth and nail against any unreasonable release dates and rather push them out than insult a costumer with poor quality. When the managers are fighting for Sales, they have now become the person who looks for a way to sweep something under the rug and to ‘bring things in’. Often you hear the phrase “Is it really going to take that long,” “Do we really need to do that,” “Customers won’t do that,” “That isn’t a typical use case,” or even worse, an admission of failure, “We’ll fix that in a service release.” We you hear these phrases from your managers and you’re in engineering, you’ve just been set up for failure. Management in engineering should /never/ be given incentives to ship on time above having a product of the highest quality and they should be willing to fight for this.
Now on a tangent, I’ve thought a bit lately about what a Roadmap means. I’m sure this has come to many already but a new developer must pause to think about why it is called a Roadmap. A Roadmap isn’t just a list of things you need to do or plan to do. It is that list of things in a two dimensional list, your map, and their distance from each other represents how related they are in the code and feature set. Now, often companies elicit feedback from their customers which will prioritize these features. If you were to superimpose this onto your map by using circles and those with a higher priority are darker and have a larger radius, you can start to see what customers are calling for and what all the features in the vicinity affected by the demands are. The goal of product management, as I see it now given what I view a roadmap as, is to play the traveling salesman. They should look at the map and start around the highest priority item and then figure out what is the shortest distance they need to travel to get all of these things implemented? By minimizing distance he will save development time because this helps to group like features together which means less context switching on the part of development. There is no later ‘coming’ back to figure out how something worked again. This reduction of context switching will also lead to better quality since all the gotchas a developer discovered while in the code the first time will still be fresh in their mind as they move to the next related feature. Another nice thing about this view of the Roadmap is you can see the hot areas and when you implement all the things in a hot area you haven’t just released a feature, you’ve released a feature set which will more serve the customer in what they were trying to to. So perhaps an example of what I’m saying here is a feature to send messages to customers is in high demand. A related feature around this is that you have a notification system in your product but it really isn’t that good, maybe bug ridden or just flakey. These two would be on the roadmap and somewhat close together and while customers are not calling for fixing your current notification system the overlap of the demand for messaging will dragged notification in as a necessity.
Anyways, this is my brain dump for now. I think I might have exceeded my quota for thinking today.
~ Rod

]]>