No More Demo Code!
No More Demo Code!
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
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.
Opinions expressed by DZone contributors are their own.