Functional Debt
Thanks to Ward Cunningham, we now have a wonderful metaphor "Technical Debt" which explains the common problem of skipping a little bit of design or missing out that little bit of refactoring to meet a deadline. Whenever we cut corners there is a very good chance we are taking on more and more Technical Debt.
Money to Burn? Invest in Functional Debt
But is there a flip side to this? I think there is and the term I would use is Functional Debt. This is tied firmly in the YAGNI camp and relates to functionality that is developed without a need (or worse still a test). Applying too much design, or developing generic frameworks with no business reason to do so inevitably leads to a solution which is over-engineered. Of course, over-engineering as a term has been around for a long time, but I prefer the term Functional Debt, because this ties it back to money in a similar way to Technical Debt.
Debt is a term that evokes emotion and is easy for people to identify with and it is this capacity of the term to clarify the issue with a certain practise. Over-engineering as a term doesn't evoke the same response and certainly doesn't suggest a loss of money in the same way that Debt does.
There are of course direct, easily measurable costs involved in creating unused functionality and that is the development costs, however, there are many more subtle costs that are easy to overlook. There is the missed opportunity costs associated with not doing the right thing. There is the project overhead costs in maintaining code that is not used. There is the project overhead costs in increased complexity and time for the standard day to day activities of testing and refactoring. There is the increased maintenance costs since it is now harder to understand the code for support personnel...
One of the biggest causes for Functional Debt I have seen is a lack of customer (business) involvement or direction. Left to their own devices, IS departments naturally build overly- complex solutions to simple problems. Without a business value attached to a piece of functionality (actually to a problem that is solved by a piece of functionality) it is only too easy for the IS department to burn money like there's no tomorrow.
Vision >= Solution >= Problem
I'll admit it, I'm not 100% agile since I tend to like solutions. I would prefer a problem to solve, but if a problem is intangible I often find a solution is a great way to explore the potential and help express the underlying problem.
It is worth noting that innovation and invention are solutions and not problems. When you apply for a patent, you don't patent the problem, you patent the solution, why? If there are multiple solutions to any given problem then wouldn't we want to patent the problem?
I also find that quite often the solutions I am exploring are the result of a problem that I have assumed was well known and in actuality is not; it is in these moments that using the solution to derive the lowest common denominator of a problem stated as a user story can ensure that everyone is speaking the same language.
But given a solution, do we always need to know the problem? My pragmatism (and a few lean principles, i.e. waste) would state that if the solution brings value then run with it, if not ditch it. If on the other hand the solution seems too constrained or lacking in features/functionality, then why not exploit the solution as the basis for a vision? Indeed many visions are just that, solutions to problems, expressed in a language alien to most developers.
So given a vision expressed in an abstract form vs a vision that is pinned against an actual solution which is easier to understand and less likely to be misinterpreted? I know which I'd prefer...
Do solutions have value, obviously; must we always mine problems, hmmm...
Ten Commandments of Agile
I've posted a few entries now about my unease with the fuzziness surrounding Agile and how I feel it needs some clarity so I thought I'd have a quick stab at it.
The following commandments would be my first stab at such a list which would apply to any person who is part of or interacts with an Agile team.
- Thou shalt not negotiate quality
- Thou shalt not prophesize without proof
- Thou shalt not falsify the facts
- Thou shalt not force thy wishes on others
- Thou shalt not discourage those around you
- Thou shalt not disparage the actions of others
- Thou shalt not work without committment
- Thou shalt not focus on more than a singular item
- Thou shalt not demonstrate incomplete work
- Thou shalt not act in isolation
Of course, this is just a bit of fun on my part, but I fail to see why there can't be a set of golden rules of Agile? This is also a very quick list, so who knows, I may revisit this at some time to refine it...
Also, please note, I'm not being remotely fuzzy about this... I'm not saying
"I value not negotiating quality over allowing any old crap in the code..."
Could Agile Have Evolved?
DNA
I've been researching material to support an article on my company blog entitled "Agile Dictators" and it left me thinking about how Agile started in the first place.
The more I reflect on this, the more I am left feeling that Agile is actually a mutation in software development and this is one of the major reasons why Agile is so difficult to master. I'm wondering whether agile would ever naturally evolve in a small team left to their own devices and I simply can't envisage it. Of course, this will now remain an academic hypothesis since Agile has now stamped it's influence indelibly on the DNA of software development.
Software development as a craft suffers from unnecessary complexity and I fear that Agile, which initially thrived in simplifying (or removing) this complexity, is now becoming itself encompassed in unnecessary complexity. Despite agreeing with much of the sentiment of the software craftmanship manifesto I just can't bring myself to sign up to it yet. I struggle to see the benefit of more fuzzy aspirational statements and would prefer to see a clarity of vision and roadmap to achieving it.
Fundamentally Agile is fantastic, but sadly the passionate discussions, raging debates and conflicting methodologies don't clarify anything. If Agile doesn't clearly define itself soon I fear yet another mutation may take centre stage and Agile will end up being just a blip (albeit a very significant blip, where we gained sight) in the evolution of software development.
Love Wave, Hate Google
I've not tried wave, but I'm already loving it, I can see immediately how it addresses one of my wishes from a previous post... But I'm hating the wait. I had always looked to Google as a very pioneering company and certainly assumed they applied agile principles. However, I can't see how such an important disruptive technology like Google Wave has managed to stay behind closed doors for 2 years...
I've been working on a few internal projects for my company of late and this has involved working in a distributed fashion (yes, pairing by phone), and during some of these sessions I can immediately envisage the benefits of using Wave.
Surely there is at least one complete, tested feature they can roll out to production? My concern is there are still some fundamental challenges facing the team, and I would not be surprised to find it being concurrency issues, so as the potential end-user of this technology I'm going to make it clear, I don't particularly care about have multiple users editing the same document in real-time with transparent, asynchronous updating... Let me edit, commit, refresh, etc as a simple starting point... But whatever you do, let me do something before I find a simple alternative...
To find out more about wave, visit the wave site http://wave.google.com/, and especially watch the google I/O presentation...
- Getting prepped to have the big mid-life crisis...
My Links
Recent Posts
- Functional Debt
- Vision >= Solution >= Problem
- Ten Commandments of Agile
- Could Agile Have Evolved?
- Love Wave, Hate Google
- The Real Value of Test First is the Thought Process
- Big Red Button
- Delivering Early
- Agile Requires Skilled Developers
- Slack Is Important
Archives
Blogroll
- Alex Adamopoulos
- Alistair Cockburn
- Andy Hunt
- Ben Hoskins
- Dan North
- Dave Thomas
- James Shore
- Jim Highsmith
- Joel On Software
- Martin Fowler
- Michael Feathers
- Object Mentor
- Scott Ambler
- Stephen Walther
- Ward Cunningham
Tags
Rate This
