This is Mark Nijhof's Typepad Profile.
Join Typepad and start following Mark Nijhof's activity
Join Now!
Already a member? Sign In
Mark Nijhof
Recent Activity
I think in different scenarios there are different reasons for allowing technical debt: I know a situation where software projects are delivered to clients whom also have a maintenance agreement. There the actual quality of the delivered software is quite low, but the service provider figures that when the client needs something changed they will have to pay for these changes. So if I am a cynical person I would even go as far as saying, delivering bad quality will earn the service provider more money in the long run. Of course this is in the very long run not the best strategy to play, but hey they deal with that later. So the client wasn’t told. Then there is the wanting to win a contract and because of that having very low estimates, of course the contract states the usual asserts about quality so when the potential client sees these offers they will most likely pick the cheapest one if both offer the same functionality. Here again a case where the client wasn’t told. With internal development this is a different case, here the developers (if they know) will speak up and tell their boss or PM that if they do this and that in a ‘faster’ way that this will mean that at a later date it needs to be corrected. They do this because it has bitten them in the *** before so they learned to cover their own ***. Here the problem probably lies in the pressure of bringing something to market, everybody knows that it isn’t pretty and needs to be fixed in the near future, but hey it is a new release and before the competition. So they were told, but perhaps not what is would actually cost them in the long run. So could we say that we are only living in the now, and we miss the capability to look further into the future? And even if we see far enough into the future to see the collision about to happen, we tend to ignore it, think that we will deal with that when the time comes. So I agree we need to change the behavior, and I believe that we need to change the expectations that our stakeholders have from software development. Isn’t it weird that a client expects that a software development project will run over time, will costs more than estimated and perhaps not even do what was needed? But I am not sure that putting the emphasis on the value they lose by choosing the shortcut will do it. It wasn’t there to begin with; I have to pay more to get more value, right? In many cases they don’t even get to make the decision with all the facts presented to them. In the end I think it is about trust, our stakeholders need to trust us to deliver the appropriate quality, and we need to trust them that when they tell us to take a short-cut that we get the opportunity to fix this later on. So maybe before that trust is there we have to put in writing (a backlog item or something like that) the extra work associated with bringing back the quality in the system after having taken this short-cut. And add it to the backlog straight away, that way it needs to be paid right then and there (when the decision is made) the only thing they then influence is the initial delivery date, with a clear indication that this will cost them x amount more? (sorry for the long comment without really saying anything)
Toggle Commented Nov 9, 2009 on Beyond Technical Debt at Michael Feathers