Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans

Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

No More Demo Code!

09.08.2010
| 19135 views |
  • submit to reddit
How often have you lived this scenario? Customers and managers beg, scream, and demand more features tomorrow. No matter what you tell them you can get done, they ask for more. So you work very hard... you do Whatever It Takes. You consume vast amounts of Red Bull, Mountain Dew, and other caffeine rich beverages. You eat cold pizza and food from a vending machine. You work late into the evening and most weekends. You sacrifice your personal life for the good of the company.

And you get it done! Sure, it's prayer driven development... It's duct tape and baling wire, but it works!! Mostly... I mean, on that crazy schedule, you didn't do a lot of edge case testing, or much testing at all. And you skimped on error handling. But it handles the one set of data you had time to feed it. So the demo is scripted. Click it in this order. Do this, then that, but not out of order! So the demo goes decently... the app only locked up one time. Everyone was reasonably happy.

And that's when the trouble started.

The customer saw what appeared to be a working application. Your management saw the same thing. You said "It's just a demo" and "It's not ready for production", but they didn't hear you... they were watching that great demo. And to be fair, it wouldn't have mattered what you said... they wouldn't have heard you.

So when you returned to you office, arriving late in the morning, trying to recover from so many late nights, and you found your manager waiting for you at your desk. "Where have you been? We've got work to do!"

 Apparently the customer signed a contract with your company for that wonderful software, but they need more features added. Of course, they need in slightly less time that you'll need to add the new features. When you helplessly tell you manager that the demo wasn't done, it needs to be cleaned up, productified, robustified, and refactored, they laugh and assure you none of that is necessary. Just slap a few more features on it and push it out the door! I know you can do it they say.

This happens all too often, and it's a problem we have to solve. Your managers rarely understand what you do, so they take your time estimates as their best guess for how much you can actually do. So start estimating differently.

In a nutshell, most of us know what great engineering practices are... we know we should be writing automated tests. We know we should review our code with another developer. But we never make the time.... we're too busy fixing the demo code from last week.

 Sit down with your manager and ask them in plain language whether they'd prefer to have five solid features to demo or ten flaky ones? Would they rather have a product to demo that won't crash, and can be more solidly extended, or the same crazy rat race they've been in, where they get embarrassed by delays, crashes, and bad software.

Most managers I've had this discussion with always choose the solid product. They asked for the ten features because they felt you could provide them, and you did. If they could've gotten fewer features, but had confidence that the fewer features would be very solid, they'd take fewer robust features every time.

Here are a few things you can do to help stop shipping demo code at your organization.

  • Put separate tasks in your system for coded features and automated tests for those features. Unwritten tests will be instantly visible and not writing them will be a choice, not an oversight.
  • Run your tests in a continuous integration system. Every time the code is touched, the tests are run. Commit to fixing every break as soon as it's noticed.
  • Every time a bug is found, wrap it in a test. This will strengthen your test suite in the areas your code is the weakest.
  • Review every piece of code you write with another developer before you check it in. Knowing a peer will look at your work will change how many shortcuts you take.

What will people remember about your code? That you completed 80% of the "must have" features instead of 100%, or will they remember that your product crashed repeatedly in the demo, then you weren't able to pull it all together into a shipping product? I find people only remember whether your product was rock solid or whether it crashed.

They'll never remember that you took all those shortcuts because they asked you too. They'll just remember you as a bad developer. And I'm not so sure they're wrong.

Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Luigi Viggiano replied on Thu, 2010/09/09 - 11:08am

True, your story is common. But think about it: bad devs ship bad software quickly, then they take weeks or months to fix all the bugs.

 Another option is... ship the "demo" but make evident there are A LOT of bugs BECAUSE of the code is a demo (even if there aren't)... then refactor (or rewrite) it. I know it's hard, but it works. 

I've been recently provided some features literally "on the fly" because needed immediately. After, when I had time to breathe I refactored and unit tested (around 100% coverage). Not a single line of the original code was kept, still the deadline was respected and no issue.

I do not fully agree that you never have to "quickfix" things. Sometime you have to follow business emergencies, and by experience, later there is always some quiet period (that other developer pass bugfixing and being late).

Using the downtime to write unit tests is much better than being always late and doing bugfixes. So make good use of the downtime.

 

Tim Boudreau replied on Thu, 2010/09/09 - 1:35pm

Napkin look-and-feel is an interesting solution to part of this problem (demos looking "finished") - make it look hand-drawn. Probably conceptually that approach could be applied anywhere.

Alan Gregory replied on Fri, 2010/09/10 - 7:47am

Agree with Tim, we now use SketchFlow for our Demos and use these as concepts to show our business users.

They can see from the sketchy screen designs that 'its not real' even though the data might be real. What customers mostly want in my experience is a warm feeling you have got their requirements and can provide a solution to their problem.  The moment you show the polished screens, even though they might be cardboard cut outs the race is then on to fit the data behind the polish.

Once you move away from showing a real screen, to showing something that looks 'conceptual' this becomes easier.

It is up to us in the software development business to manage expectations, those of our managers and hopefully, allow them to manage the expectations of our customers. If we ourselves, interface to the customers, it is also up to us to manage the customer's expectations. Unfortunately software is shiny and people get distracted by the gloss, take it away and you will find that customers listen a little more.

Sketchflow is not the only solution to this problem, drawn storyboarding of solutions helps customers get the point without writing code at all; working in XAML and C# Sketchflow suits our needs.

Jared Richardson replied on Fri, 2010/09/10 - 10:17am in response to: Luigi Viggiano

Hi Luigi,

I'd argue with a few points in your reply, but thanks for the comments!

First, "ship the demo, but make evident there are a LOT of bugs..." This makes you look bad, makes your boss look bad, and your company look bad. If you provide noticeably buggy code for your boss to demo, you might not have a job very long. I know you wouldn't where I work. People expect the demos to work, especially when these are customer demos.

Second, adding features, then refactoring the code out of existence is a great idea, but you're assuming a sane timeline to make those changes. It sounds like you've got that time, but most shops I've worked with just don't get that enough time to clean things up later. Once a mess is created, it takes a lot longer to clean it up than it would have to do it right the first time, and it usually doesn't get cleaned up. Sure, we'll occasionally have to take shortcuts. That's life. But I want to make that the rare exception, not the rule.

Finally, using your downtime to add in tests after the fact... argh! This approach completely misses the most important reason to write tests and code at the same time. It creates different code! The routines are smaller and are very testable. Writing tests after the fact only provides you with a test case. Writing your tests first provides you with a test case and much better code as well.

And again, most shops don't get that much downtime. They move from release to release. The downtime exists, but it's rarely enough to do a decent job of cleaning up a sloppy code base or creating a useful test suite. Not doing things right the first time around has, in my experience, caused more problems than it's ever solved.

Jared Richardson replied on Fri, 2010/09/10 - 10:19am in response to: Tim Boudreau

Hi Tim,

If it works in your space, then tools like http://mockflow.com/ do a great job. In my last few areas the demos have been used to sell the "product" to the customer, so it's got to be more finished. But I like the idea a lot.

Trevor Lane replied on Fri, 2010/09/10 - 4:35pm

Hi Jared, I fully agree, However I must say I use a demo to sell a concept. I use a product to sell a product. I have NEVER used a demo to sell a product, and if you do I think you should stop. For all of the same arguments you made in your article.

Dan Wiebe replied on Fri, 2010/09/10 - 10:52pm

If you use test-driven development, you don't have to worry about what parts of your code are tested and what parts aren't. It's all tested, otherwise it wouldn't have been written; and you can savagely refactor it, when necessary, with confidence that A) you'll know when you're done (by which I actually mean that you'll know when you're _not_ done), and B) once you're done, the refactored code will be of high quality, not low quality.

Furthermore, if you test-drive a demo--preferably a thin, quick end-to-end clear through the application domain--then it _will_ be production-quality code. It won't provide much, if any, business value, but it'll generally be inspiring enough to generate a backlog of user stories, and once the stories are implemented, you still have production code.

Writing good test-driven code requires the ability to write good tests; you're not born knowing how to write good tests, and you won't learn it from a book either--you'll learn it from a pair partner. But once you know how to write good tests, you'll generate high-quality code significantly faster than you ever generated low-quality hacked-together bug-ridden garbage in the past.

Not at first, of course. While your project is under 1000LOC, you can keep enough of it in your head at once to make faster progress without tests. But it won't stay that small for long, and once you're over 10000LOC without tests, you're up the creek without a paddle when you have to add a feature that breaks a bunch of assumptions you started out with. It'll already be getting brittle enough that you don't dare touch significant sections of it, and the kludges you hack in to avoid touching those sections will make it even worse.

But drive it with good tests, and it'll never get brittle. Even big refactorings will consist of a bout of bold hacking and slashing followed by a period where you get the tests running again.

Jared Richardson replied on Sat, 2010/09/11 - 8:34am in response to: Trevor Lane

Hi Trevor,

Unfortunately, every industry is different. I've seen enough areas where the demos ~are~ the sales pitches that I wrote the article... and it seems to be resonating with a lot of people. The concept you're referring to, using a very lightweight demo to sell an idea or concept, is done internally at the shops I'm thinking about. Then, once a "real" demo is built, it's shown to the potential customer. Finally, once funded, it goes into production mode. My concern is starting with a hacked together demo that we have to use as a foundation. There are a number of industry areas where this is the norm, and others where it's not.

No matter how many times I've heard people say "This is just a demo", I don't think I've every had the audience remember that phrase... or perhaps they remembered it, but didn't understand the implications. In my experience people remember the working (or crashing) software, not the words we try to put around it.

I'd like to see developers, across industries, choose to adopt great engineer practices and use them in every situation. You never hear a hardware engineer offer to skip a set of tests (like a heat stress test) for a new part. They know by doing so, if the part fails in production, it's their fault. They look bad, the product fails, and the company suffers. But in software we take shortcuts ~all the time~. And then we blame our managers for asking us to move faster. We need to step back and take responsibility for our own work. If we refuse to skip the testing and validation of our code, we'll turn out better code.

Okay, that last paragraph turned into a general purpose rant, not aimed at you Trevor. :) // Stepping away from the soapbox.... //

Jared Richardson replied on Sat, 2010/09/11 - 8:43am in response to: Dan Wiebe

Dan, very well said.

I hope that developers, across industries and technology barriers, are starting to see that shortcuts make ~us~ look bad. If we continue to churn out crappy products, then we should expect to be treated like hacks. If we turn out solid, reliable products, we should expect to be treated like professionals.

I tend to start new teams with defect driven testing because writing good tests is so difficult, then introduce mock client tests (use the code from your test the way you expect it to be used by client code), then tackle TDD. I've had a much higher success rate with this type of gradual adoption. I think it helps developers to learn that automated tests are a rock solid safety net first, then they're willing to change the way they code to accommodate TDD. Then, once they've experienced that type of coding, few developers are willing to go back to "prayer driven development" (write it and pray it works). ;)

However, if you've got a Dan Wiebe or another experienced TDDer sitting near you, go grab them and jump straight in! Hard core TDD changes the way you write code in so many ways.

If we write great code from day one, we'll never be put in a situation of cleaning up our own messes. If we become advocates for great practices within our organizations, and teach them to the people we work with everyday, then we won't have to clean up our coworker's messes either.

How much more fun would your job be if it was mostly adding features instead of living in the debugger?

Thanks for the great comments Dan!

replied on Sat, 2010/09/11 - 1:12pm

Great article until it came to the point about giving advice on how to deal with this. The best way to handle this situation is to pack your bags and move to a better company. The company you are currently working for has serious systemic problems and does not value you as a person or as a worker. Let them fuck up and fail on their own and get the hell out of there. Next time, don't .put your life and health at risk to satisfy some 'manager'. Value yourself and others will do the same.

Jared Richardson replied on Sat, 2010/09/11 - 2:21pm in response to:

While I'm currently a full-time employee, the article is about the many situations I've encountered as a consultant more than my current situation. And this kind of problem is quite often not caused by management, but by the developers. We provide shoddy work very quickly, so they become used to that level of quality and that timeline. Offer them a better alternative and most good managers will take it.

I firmly believe that most people want to do the right thing, but when it comes to software, most of us don't know what that is. I always try to drive change before I consider leaving. For me leaving only comes when I'm unable to see a way that you can make things better. I'm less concerned with perfection (or some semblance of it) than I am with people who are improving.

And it's not that they don't value you. They don't understand how software is built, or the impact their choices have. It's often an education issue, not a moral one. (Not always though...)

I think it was Michael Feathers (but I'm sure) who said "Change your organization, or change your organization." I think that really applies here. If it's truly just management who don't understand what needs to be done, they can often be educated. If they can't, then I agree... run for the door.

Another great quote that's not really related to your comments, but I was somehow reminded of it ;) was from Kent Beck. "I can finish it tomorrow if it doesn't have to work".

Dan Wiebe replied on Sat, 2010/09/11 - 8:07pm in response to: Jared Richardson

Thanks for saying nice things about me.

You're right that the single most important measure of a developer is not his cleverness with the language or his facility with a particular technology stack, but the sustained velocity at which he can add solid business value to a project. If you can add business value to a project at a sustained rate of 3.5-4.0 story points (at least as I define story points) per week, then whatever you're doing as a developer is working. (If you can sustain a rate of 6.0-8.0 a week, you know things that would be of significant benefit to other developers, and you probably ought to spend some of that excess velocity pairing with them so that they can learn it.) The key word is "sustained." If you're working 45-50hr/wk to get those numbers, that's not sustainable. If you're racking up technical debt to get those numbers, that's not sustainable. If you're modifying production functionality under green to get those numbers, that's not sustainable. But with the right practices, that sort of velocity is not only attainable for the average developer, but sustainable. What are the right practices? Hey, we're Agile: the right practices are the ones that enable you to achieve that sort of sustainable velocity or more. Yours may turn out to be different from mine; but mine have been commercially proven to be dang good.

The quickest way my company's found to make a client team Agile is to start them right into hard-core TDD from Day One, but to make sure that each client developer is paired with an experienced Agile coach. We start out with the coach driving just about all the time. After a day or two of that, the coach will write a test, the client developer will make it green, and the coach will refactor the client's code. After awhile, the client is able to refactor his own code. The length of the I-set-em-up-you-knock-em-down stage varies per client developer, but I've never seen it take less than a week. Eventually, we move on to real ping-pong pairing, where I write a test for you, you make it green and refactor, and then you write a test for me and I make it green and refactor, then write a test for you and so on. Sometimes the client developer never gets this far: he just turns out not to be cut out for Agile. If he does, though, shortly thereafter he's considered officially Assimilated and starts receiving training about how to be a coach in his own right.

The project I'm currently on involves writing Groovy and Grails code with an IDE setup that doesn't allow use of a symbolic debugger at all: I'd have to use println statements instead if I were to go that route. But I hardly miss the debugger, because I have tests. You use the debugger when you don't know what's going on and you have to find out; but when your tests are green, you already know what's going on; and if you're writing your tests correctly, then you're never more than ten minutes or so away from green, so there's no real need for a debugger.

Dan Wiebe replied on Sat, 2010/09/11 - 8:17pm in response to: Jared Richardson

Very true.

But if you teach your product owner how to be an Agile product owner, and if he listens to you, not only will he learn to value you more than you've ever been valued before, but you'll learn to value him properly as well--which is something that far too many developers don't understand.

I remember one Agile-transformation project we were doing where a fledgling product owner freaked out at the first demo, when A) it had been only a week since the project had started, and B) she decided that some of the demoed functionality would be better if it worked differently from the way she'd originally said she wanted it.

Calming her down was a bit of an adventure, but I won't forget the comment she made afterward.

She said, "I'm used to ordering a Big Mac and then going off about my business, and many months later having a buggy, crashy Big Mac delivered, way over budget and way past deadline. That's been my experience, and that's what I'm comfortable with. But I have never ordered a Big Mac before and then immediately been enlisted to help butcher the cow!"

Armand Marius replied on Mon, 2012/06/25 - 11:50am

I like this idea. No more demo code means a lot of interesting stuff available for us.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.