Big projects are just a bunch of little pieces

October 13, 2007

Breaking down requirements

One of the most underrated skills in developing software is to break requirements down into smaller pieces. You can do that several ways. For example you can conclude that to be able to write the program, you need to have the database in place. So you start with database design. Then you go on to write the business logic on top of it. Finally you add the user interface. Let me call these pieces technical slices.Another way would be to slice by functionality. For example we start with the administration tool, so data can be added to the system. Then we write the functionality for the shop. Then for shipping the items. etc.Very often those slices appear to have dependencies on others. For example:

  • Can you write the business logic without the database?
  • To be able to sell items, there has to be a way to add items to the system

For agile development it’s crucial to be able to break down ideas into very small pieces of independent functionality. Why? Because you want to let the customer chose what is most valuable to him and work on that. If the pieces of functionality (called “user stories” in Extreme Programming), aren’t independent the customer has no choice.Little pieces of functionality means it can be implemented and ready to use in about 2 weeks or less. Finding those pieces is a new skill - it isn’t taught at schools.Breaking the requirements down into little pieces has a lot of advantages but also some disadvantages.


Little pieces of functionality…

  • …are done quickly, giving the team a lot of small successes - increasing motivation
  • …minimize risk, because you can do the tough stuff first and find problems early
  • …help the project make money fast, because you can have a valuable subset of functionality ready for use early, decreasing your time to market
  • …enable changes in requirements, because things that aren’t implemented don’t have to be and new ideas can make it to production fast.
  • …help you recognize problems in performance, usability and even help you discover misunderstandings. Early, of course.
  • …are easier to test (because there is less to test) and easier to test automatically (because they are independent)


Little pieces of functionality…

  • …never stop coming in, making it hard to put a price tag on a project at the very beginning
  • …never stop coming in, making it hard to say when you’re done with everything
  • …change with every thing the customer learns during the project, making it impossible to tell the customer what he’s going to get in the end
  • …work bad with a rewrite, because well, it just has to do what the old software already did.

A lot of the disadvantages are strongly dependent on the structure of the contract. A lot of customers (and IT people) look at building software the same way as building a house. They want to know how the house looks, they want to know when it’s done and how much it costs. This doesn’t work very well with houses - and it doesn’t work at all with software.

Posted by Jerome Mueller

Leave a Reply