Agile Insider reality bytes…


Digital Charity Shop

I bought my wife a sony ereader for her birthday in November and despite the fact she wasn't too happy it wasn't shiny or smelly she has since not put it down...

Her friend has a kindle and the other night my wife asked whether I would be able to transfer one of the books she just finished reading from her reader on to her friends kindle.  I wasn't entirely sure I could, since my first thought was drm is probably going to prevent this.  My second thought was why???  In the non digital world, once my wife has finished a book there would be nothing preventing her giving it to her friend but in the digital world this isn't easy, but why...  Surely it should be possible for her to transfer her rights to someone else... Of course, someone will probably point out that this is already possible, but it was my next thought that really got me.

I wouldn't say we were minimalist, however we do tend to have a 'clean out' regularly which usually involves a trip to a local charity.  We religiously donate the books we have read, the toys we have replaced and various other things.  But now that my wife is using a reader there are no books to donate 🙁

My solution, It doesn't exist yet, but I've bought the domain and intend to find like minded individuals to help me set this up to receive unwanted digital content and resell them with all profits going to charity.  If you'd like to help me on this journey I'll be extremely grateful 😉

Of course, this won't just include ebooks, the solution is also begging to include any digital content - movies, mp3, software, apps...  And just to be entirely clear, I'm not interested in £1 of each purchase goes to charity type deals, it all goes to charity...

So can you help?

Tagged as: , , Comments Off

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

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.