Demo and Discovery

Define: Demo and discovery

Demonstration and discovery is what we call the regular meetings we hold with our database manager and the stakeholders (who might be the whole user group, or a representative sample). It’s where we figure out the details of the use cases we’re developing. Back when I started developing in FileMaker, we used the old school development method called Waterfall.

Waterfall

The old school process puts huge effort into writing these detailed requirements that describe everything about the database, including what every single function should be and often even every step the software will take to get each job done. Since so much effort goes into creating them, the requirements are committed to stone, and they are rarely changed during development. In this process, production is the king. The thought is: we have a product outlined and we know exactly what it needs to do. Here’s the document that describes what we know, now you go off and make it so. This process is called “waterfall” because from concept to requirements to handing off to a developer, the process moves forward for really long time before there’s anything you can demonstrate or test.

In this scenario, the user may or may not have been involved in creating the requirements. Old school development is agnostic on that point. A manager, or an engineer, may have written the requirements. But even if end users had input on the requirements documentation, they don’t come back into the process until after development is done and the whole database is ready to test as a unit. Users test, somebody consolidates their feedback and gives it to the developer, who fixes the bugs (the ones that were found), and the project is deployed. Waterfall development can leave lots of bugs because it’s really hard to test a whole software program at one time. So often, the deployment phase—with live data and sometimes harried users—has multiple bug fix/maintenance releases, and while that’s happening, the product gets analyzed for new features, new requirements are written and the process starts over for the next whole number release.

New School: Agile

So in response to waterfall’s weaknesses, a new school of development, called Agile, started to gain traction. Agile is so widely used these days that’s it surprises me a little to remember how revolutionary it seemed at the time. Waterfall development can feel constricting because you’d often learn something in the course of development that cries out for changing the requirements. But if you do change requirements, all that time spent up front refining detailed requirements is wasted.  The engineers, marketers, and managers who’d spent so much time on developing requirements worried that their analysis would be thrown out the window if requirements were allowed to change along the way.

Here’s how Agile development works: you still start with a specific need for a piece of software, and requirements are written. But they aren’t detailed. Agile requirements describe what the database needs to do, but not how it will get those tasks done. Now the first thing that happens is that a team of requirements folks (which should include users or user proxies) meet with the development team and they analyze a small set of the requirements. Those are developed, demoed, tested, and bugfixed. Then the team bites off another chunk and runs the analyze, develop, text process again. But in this cycle, you get the benefit of whatever you learned in the first cycle. You might have thrown some sample data into the prototype database and found out that the original analysis about structure or how some feature needed to work was wrong. So you bring that up at the next analysis meeting, figure out how to adjust and move on. This cycle gets repeated with new requirements until the whole package is built.

With Agile, the software has been tested, bugfixed and improved throughout the whole development process. Bugs and errors are fewer and less serious at deployment. It’s true that the package often looks fairly different than the original concept, but it tends to ends up with more satisfied users because of the benefits of iterated development.