Gathering requirements from customers is a never ending cycle. It's also something that is pretty much impossible to do within a single iteration. It's for these sorts of reasons that software teams tend to shoot for more agile models of development like eXtreme Programming, Rapid Application Development, Scrums etc. However at the root of any IT project there has to be a business driver that steps outside the technical and focusses on the fiscal opportunities the system can present.
I'm writing this as a result of an experience I had with the MD of my company a few weeks back. I've worked under a lot of managers of which the majority have been really nice people but perhaps too afraid of challenging me to any confrontational level. The other day we delivered a presentation to the MD - the main sponsor of a "proof-of-concept" that we needed to deliver to a client. The prototype had been hacked up within the space of a week, with no planning and no solid requirements. It was really just a mash-up of a number of technologies to prove that they could peacefully coexist and achieve a certain output the client was after.
The MD was pretty satisfied with the outcome - actually he was too satisfied. As a result he started to toy with the idea of delivering the concept as the final product instead of starting over again. Hearing that didn't feel so good. I started to wonder about the support issues, the maintainability issues, what happens if it needs to be extended? Without much hesitation I voiced my concerns, thinking that hey I have a pretty clear-cut argument. Unexpededly I hit a bit of a brick wall.The conversation went something like this:
"Why do we need to redevelop it?"
"Because this is a prototype, it hasn't even been tested, it's probably full of bugs and is unstable"
"How do you know it's full of bugs and is unstable?"
"Because we haven't had time to test it, plus it was never designed properly from the start. It's just a throw away system that was developed to demonstrate that what was required by the client could be achieved."
"You just showed me that it does everything I asked you for, why would you want to start again?"
"Because there's no proper design structure, it's bubble-and-squeak"
It was throughout this volley that I realised I was really just spinning my wheels. However later on I started thinking that there was a deeper meaning. As a developer of however many years, I've always tried to improve my skills and design the most elegant systems I can to ensure that they're extensible, maintainable and stable. Granted that most of these systems tended to have a decent amount of funding behind them, it's then appropriate to put in the effort to ensure the quality of the software.
But should throw-away prototypes and smaller system developments be given the same amount of love and attention that their large counterparts should? I now maintain that they shouldn't. If I write a tool or small utility that I know has a very small chance of being upgraded or extended, why should I invest additional time and incur additional overhead in creating a solution with such a narrow focus? Business will always have a need to churn out a heap of small, low-value apps, which need the developer to be a human-code generator - but is that something to be frowned upon?
I think it gives a chance for the developer to shake off the chains of proper design, process and implementation, and go nuts pouring as much of their past experience and knowledge in the ultimate development model - hack programming.
Can it be applied to all projects? No. Do you need to be 1337 to do it? Perhaps do it in moderation, especially if you're a jnr dev. Ultimately if you're cutting code for a profiteering business, everything comes down to the $, and that adds to the equation ROI and how much of your valuable time you need to invest in the little systems. I used to hate the concept of hack programming, but maybe it does have its place afterall?