You're probably not going to need it

Posted 2012-05-31
Written by Matt Frost
Category code

Those of you that know me know that I am a proponent of Agile.  I have found that a lot of the principles work extremely well whether working individually or collaboratively.  However, as has happened with the definition of Agile, there are some tenets that I feel are misinterpretted and used as an excuse for writing poor code.  The idea that "You're probably not going to need it" came up at PHP Book Club the other night, and it got me thinking a little bit.

I work for a consulting firm, which means that generally speaking we're working to client expectations.  The never ending challenge is being able to set client expectations and meet them with some degree of regularity.  That's a topic for another day, but what's relevent is this; in order to meet the client's expectations we have to work to simplify the functionality and write it in a way that eliminates major refactoring.  Long story short, that's hard to do.  We're hoping that we deliver everything we promised, with little more, on time,so the client has a pleasant experience work with us.  Then, we can move to step 2 or feature 2 or whatever.  The idea that you're probably not going to need it is very easy to cling to in these situations, and so we have to determine how to make the code sufficiently simple.  We have to assume because they are a client that is leaning on our expertise, that at some point something is going to change and that we should be ready for that.

What I find far too often is that simplicity is often translated to rigid, tightly coupled, "think only of the present" solutions.  They are tempting because the client sees them quickly, the client responds, bug fixes and feature enhancements are made with relative ease in that first iteration.  It's your first date, and you're never as romantic as you are on the first date.  As feature requests come in, and trust me they ALWAYS do, you're client is becoming less impressed...bug fixes are now taking longer.  Fixing a bug in a new feature seems to always lead to a new bug in functionality that was working fine before.  So now you're spending more of their money, and you're breaking things that were previously functional, and they're not happy.  Invoices are questioned, assumptions are made, and what was once a promising partnership has become a tense, unpleasant, potentially explosive situation.

What does the ideal situation look like though?  Don't deliver the first iteration in a somewhat timely manner and you risk appearing incompetent; deliver quick thoughtless code and you look like you were just trying to reel them in.  Obviously if you're in charge of the project, communication is the key.  You need to know what your practices are and why and you need to be able to communicate it to them.  If you use TDD, explain why you use it and the benefits it has to them, don't just say the development should take 20 hours and we do 20 hours of testing.  Frankly, that just sounds unreasonable to most people.  As developers though, we're not always in charge of that communication or we don't have the ability to set those processes and procedures in place.  My proposal is this, add a word to the end...You're probably not going to need it, yet.   I've found that looking at problems this way allows you to abstract enough to eliminate major refactoring and deliver features consistently and it also keeps you from flying out of the gate with unnecessarily complexity.

If you're working on a software product, the same goes  You have a little bit more control over what is really needed and can make decisions to eliminate superfluous functionality or code.  Even so, I find that the tendency is to say "I'm not going to need this" and then lose sight of the bigger picture.  "You're probably not going to need this" is a good mindset when applied in context, it wasn't intended to be used as a cop out or a short cut.  It was intended to help you make important design decisions that value simplicity over complexity.  By applying the principle properly, we add the value of good design to intentionally well written code, I say that should be our goal.

Comments

There are no comments

Posting comments after has been disabled.