GEARS

When is Enough, Enough?

by on August 26, 2013 12:00 pm

This summer, I had the pleasure of chatting with a distant cousin who was traveling through town. He is a retired project manager from NASA, but they keep bringing him back as a consultant, so obviously they like his work. I had never dealt with him as an adult, and he was insistent we talk when he learned I was a software developer. He asked me one of the strangest questions I think I have ever heard from a project manager:

“How can I get my developers to stop?”

Now, I’m sure we have all fallen into the trap of wanting to add just one more feature, tweak one more method, to be a bit better. But we also have deadlines, don’t we? And clients that we have to answer to?

It turned out that in my cousin’s case, there was too broad a gulf between the actual consumer of the software and the people developing it. They never spoke to one another. Everything was done through intermediaries. While I’m sure part of this was due to the nature of government work, where almost everything is contracted out (and you can’t have the contractors talking to each other without a government employee being involved), but this seemed more fundamental than that. It was what I thought was the extinct mix of waterfall and cowboy programming.

Calling something “waterfall” has become a severe term of derision in lots of shops these days. And while I think the waterfall process really should be derided, it is getting to the point where processes that aren’t at all “Waterfall” are being labeled as such because someone doesn’t like them. Unfortunately it is much easier to say, and more widely understood than “non-agile” or something similar. And while I don’t have enough information to know if these projects truly were waterfall or not, they were certainly not agile. And throwing an isolated developer into the mix only made the situation worse.

When discussing agile development techniques, the list of benefits is usually skewed to those for the developers. Less time spent in meetings and more time coding. Let the code be the ultimate requirement document. Things like that. What I think gets lost all too often (and far too frequently not utilized) is the engagement of the ultimate consumer (or their representative within the company).

At the end of each sprint, the developers should give the consumer’s stakeholder deployable code with something for them to test. If they sign off on it, it should go into production.

And here’s the important part: further development on that code should STOP. The stakeholder with the responsibility for making that call has said it is good enough. The developers should move on to other tasks in the backlog. If they have ideas for how the just released code could be improved, then that should be added to the backlog and prioritized along with everything else.

Of course, this requires that the stakeholder who is supposed to make the final go/no-go decision has all the relevant data. They can’t approve a new algorithm that hasn’t been stress tested, or a new UI that has only been tested in one environment. It is our job to present them all the facts, and then let them make the decision. And I have found that if you have been open and upfront about all the design choices and their trade-offs, and engaged them in the decision making process, they almost always make what developers would consider the “right” decision. However, we as developers must realize that even when they make the “wrong” decision after getting all the facts, it is our responsibility to implement what they ask for in the best way possible.

Final Thoughts

The agile methodology and extreme programming techniques have given a lot of power back to the regular developers. We get to make a lot more choices about tools and architectural decisions about how things should be done than we did in the bad old (waterfall) days.

But we shouldn’t abuse that power either. As Uncle Ben said, “With great power comes great responsibility.”

We have to remain aware of who our ultimate customer is and keep them happy. If we keep missing deadlines, or don’t get some new feature in a sprint because we are tweaking something that is already good enough, more people will start to ask “How can I get my developers to stop?” And once they get you to stop, they may not ask you to start again, but ask someone else who knows when enough is enough instead.

– Clayton Neff, asktheteam@keyholesoftware.com

  • Share:

8 Responses to “When is Enough, Enough?”

  1. Phil says:

    This is where things like acceptance criteria and TDD can be really helpful. They define the expected checklist, and when that checklist is complete, you’re done.

    • Clayton says:

      I am finding it really difficult to get much buy-in for TDD despite its many advantages. And I think we have to be wary of it making people complacent that they have defined all the requirements by defining the first round of tests. We still have to iterate through the design and implementation, adding and changing tests as needed.

      But you make an excellent point about how TDD can help define what “Done” is more clearly than many other methodologies.

      • Phil says:

        ATDD is a necessary counterpart, and is probably even more important than TDD. That becomes the meta checklist for delivering the feature. You and the client can write that list together, agree on it, and everything is directed to making those scenarios pass.

        That doesn’t mean the list can’t change, but it’ll only change through interaction with the client, and both parties have the same understanding at any given time of what “done” means.

  2. Jerry Horn says:

    I whole-heatedly agree with this article. However, as business processes change, so do systems. I think the trick is trying to determine what tweaks make a material difference to the overall system and ultimately, support the business process. I find that changes will be requested based on an individual’s personal preference. This can create a vicious circle of changes for the sake of changing, not true improvent.

  3. Clayton says:

    I have also run in to the “vicious circle” affect, but I think that is a different problem. That is more a matter of two stakeholders not agreeing on a requirement, and the project manager not using the system to make them agree before creating a backlog item.

    When you don’t have a stakeholder that can truly represent the end user, you will always end up with “best guess” requirements. Sometimes we may not agree with that guess, but it is still our responsibility to code it as specified (perhaps in such a way that will be easy to change later).

  4. Jerry Horn says:

    I had not heard of Gold plating either. I guess the idea is that we can always achieve some sort of perfect solution if we keep working at it. Thanks for the link.

Leave a Reply

Things Twitter is Talking About
  • RT @m_evans10: @joewalnes A SQL query goes into a bar, walks up to two tables and asks, "Can I join you?"
    August 20, 2014 at 3:55 PM
  • Have you read @wdpitt's newest book? - Web Essentials using #JavaScript & #HTML5. Free PDF download via @InfoQ: http://t.co/lesuPJ770I
    August 20, 2014 at 2:31 PM
  • How can we ensure that we write unit tests with sufficient coverage? Here are some tips for success in #unittesting - http://t.co/zqytilzXXW
    August 20, 2014 at 11:31 AM
  • RT @DZoneLinks: Easily Boost your Web Application by Using nginx - Compuware APM Blog - http://t.co/wm26pvCyKm - @DZoneLinks Big Link by ha…
    August 20, 2014 at 8:59 AM
  • Interested in @unity3d? Check out @johnwboardman's tutorials for Unity game dev with #JavaScript & C#: http://t.co/exsha7cP2b
    August 19, 2014 at 3:30 PM
  • But if you have a passion for quality dev, we might be up your alley. Check out our culture - http://t.co/kWgVdxgvpG http://t.co/y4IFbUA5Ia
    August 19, 2014 at 3:04 PM
  • FRP can solve a common #JavaScript problem - asynchronous requests to the server not returning in requested order http://t.co/jB0ox7Jo4n
    August 19, 2014 at 11:38 AM
  • #RabbitMQ: messaging software built on AMQP protocol. Learn relevant concepts & how to avoid common "gotchas" here: http://t.co/ZwMXlhKyX8
    August 19, 2014 at 9:30 AM
  • We're about to send out our free monthly tech newsletter. Dev tips/articles via email. Not on the list yet? Sign up - http://t.co/aamFVCyyJn
    August 18, 2014 at 1:44 PM
  • There's a new post on the Keyhole blog by Phuong Nguyen - Functional Reactive Programing and #JavaScript - http://t.co/jB0ox7Jo4n
    August 18, 2014 at 11:03 AM
  • Thanks for the RT, @TheGrisExplores! Have a great week.
    August 18, 2014 at 9:38 AM
  • Rapid appdev has a bad rep, but there are ways to bring development time down the right way. Don't Fear the Rapid - http://t.co/aTPcAKOj0r
    August 18, 2014 at 8:31 AM
  • Code For Maintainability So The Next Developer Doesn't Hate You - http://t.co/FWTMF7Pixd 8 helpful tips to do so.
    August 16, 2014 at 12:20 PM
  • DYK? We prefer diverse views, so the info we share doesn't always reflect us as a company. See our Social Policies - http://t.co/MXhB9lE9tV
    August 15, 2014 at 3:30 PM
  • KHS summer intern Bryan Melland just said his goodbyes, headed off to his 1st year @ University of Nebraska. Best wishes for a great year!
    August 15, 2014 at 3:02 PM
  • RT @fpmoles: It's official, KC has a Spring User Group: http://t.co/vaoiGcEva4 cc:@rob_winch
    August 15, 2014 at 2:01 PM
  • Automated Testing is great for dev, but does bring a set of challenges (especially for #agile teams). Success tips: http://t.co/1acl1ngO7i
    August 15, 2014 at 1:20 PM
  • A #JavaScript promise is an I.O.U. to return a value in the future. Promises are cool. Learn about them here - http://t.co/6wCz9b7e4v
    August 15, 2014 at 8:16 AM
  • Found a great resource for folks who want to learn to code - #KC Code Noob. The next Meetup 8/20 covers #Bootstrap - http://t.co/bHom4Lvz7h
    August 14, 2014 at 2:11 PM
  • RT @nicholascloud: the mother of all javascript wysiwyg editor lists https://t.co/o83cGoHQB8
    August 14, 2014 at 11:48 AM
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2014 Keyhole Software, LLC. All rights reserved.