This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: How much should you design Upfront?
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
I follow the FeelGoodFactor principle. Requirements at first glance can be cloudy and messy. It can ambiguous and abstract, or it could just be plain daunting. However, you need to list what you can, and the attempt 'solves'. By solves, I mean a logical route to a solve, a prototypical solution to that problem, or at least common consensus by a few good men (cough). You need to get most of the areas in your head sorted, and then commit a bit of that solution in your head to paper and a review by your peers.
Here are some example of how I have conducted the last few projects, in the context of FeelGoodFactor.
Case Studies
Document Generator
Client wanted PDF and or possibly html versions of contracts and documents, downloadable from their website. They wanted the documents to be dynamic, so that it included data, their development team would inject into it.
There should be an editor for the mail merge like features, manage data templates (data fields) via XML, manage documents and map documents to data templates. A programmatic object model for adding data to the documents and rendering it out to pdf or html.
The FeelGoodFactor came once, I had established which PDF library, I was to use, and the approach I was to take.
The approach was to create a parser, mapping expressions to data, and rendering to pdf, html or whatever the DocumentWriter was required. The extensible parts where DataFields (They would constantly change, or be added to), and the format the document would be required in, PDFDocumentWriter, HTMLDocumentWriter.
I was not concerned with the website, the document management side, as I knew I would quickly create a set of tables and UI of it, there was nothing to design for the early upfront stage of design.
I first wrote the XML Schema for the DataFields, and an ObjectModel to read/write the XML, and then moved to create a parser for html, to find my custom schema expressions.
So after 2 days, of writing code, aiding my design thoughts, and prototyping 3rd party technology, I quickly decided on a few Design Patterns that would coalesce into the base design, which I sketched in UML on paper and then started coding. Within 12 days, I finished the system, complete with +-70% test coverage, and example code in the form of recipes and Reference Help file for the small Framework. I then spent two days creating a few tables, and an API for Document Management on the server, using the Framework, ready for our website team, to use and integrate within the various sites and feature points. They created a web service to wrap some of the functions and call it offsite, and it was done.
So the project had 2 days of thought, design, and prototyping, and 10 days developing. I developed in iterations of 2 days, and therefore had 5 iterations. iteration 1 and 2 was development and Unit Tests, 3 and 4 was refactoring and developing. Iteration 5 was testing and documenting.
Publishing Framework
For internal movement of files, website images, document management, it was required to move files of certain types configurable to different servers, folders, ftp and other locations. It also had to work work and accept ONIX request for books and publishable content, with managing files, such as TOCS, covers etc
After deciding on the architecture, Windows Services and Windows Communication Foundation, I created a small design prototype. I set to work creating the Web Service and Windows Service. Once that was communicating, sending any size files to the server, and not corrupting it or losing data, or anything else, I was in the FeelGoodFactor. I could then happily design each section within iterations as the project went on. The project also contained Onix publishing schema, and Onix Product publishing, with adaptors for DotnetNuke and many other facets.
This was developed over 7 iterations of 12 days each. I lead the design for 3 developers including myself. I spent the first 3 days, by myself, outlining some ideas, investigating Onix and other aspects. We had 2 meetings discussion ideas for the project. I spent 2 days creating an initial project, with hooks and areas for the team to continue on with, and gave them each a separate area to develop, with isolated objectives and isolated functionality. We integrated our work in iteration 2, and continued to code together in team system for iteration 2. We had regular scrums, not always in the morning and probably more every 2 days, than everyday. I then did iteration 3 myself, as they worked on other projects. This gave me an opportunity to delete projects in team system (they get so messy), recreate projects, split and refactor projects, drag and drop classes aroundm change Namespaces, and create a more fine grained beast. With a more fine grained set of projects and solutions, it looks a lot better, and I got that FeelGoodFactor. At this stage with had 3 separate Visual Studio Solutions with around 6 projects in each.
In Iteration 4, I was rejoined by the two developers and we set to work creating unit tests, refactoring, and adding extra rounding features. Iteration 5, we started with a day or so of design meetings and requirements gathering, and set to work expanding the solution. I continued to design a new area, while the team continued developing new functionality.
Iteration 6 and 7, I was alone again, developing the last functions, refactoring, testing and making the design stick. I also documented various bits and pieces of the 'framework' portion of the project.
Iteration 8, which is the very next iteration, has been postponed, until our client, can meet and review. We shall not continue further, as specialization, further business rules and so on are required.
So the project has totalled 84 days, of which 10 days has been spent on design, thought and prototyping. However, I probably spend about 1 hour per day, refactoring and moulding the design, while adding new features.
The database, may get built slowly as we develop, but the focus is never on the database. I treat it as a throw away resource for these smaller projects. Both projects use reusable company Data Utilities, and can relatively easily be implemented in another database platform (depending on features, but we avoid platform specifics)
Design is not dead
Design is needed, you need to sit down and evaluate things. But the key is quiet time. Design must solve the problems it set out to solve. It must be a reachable design, within the time frame. You can reach a deadline easier, if your design is within iterations and gradually getting bigger, with the project. When you design upfront, one tends to add more things that are required. Designing for problems, evaluating solutions to problems, should be done upfront. Identify the problems within the system, and solve those, by careful thought, prototyping and any tool, such as UML, if it suits your needs, but don't design every object within your object model.
It would be a wasted of time, outlining the complete UML drawn object model, instead draw packages and the very important classes. Then create a set of rules/standards for the developers to follow, when creating the rest of the model. Also set a rule, that if you have to 'think twice', communicate with the team lead, to verify your thoughts. The same goes for when you cannot concentrate, perhaps never had breakfast. Get your team leader to pair program with you for a little bit. I call it The 'PushStart'. All of us need it from time to time.
So design until you feel that FeelGoodFator, and then develop an iteration, until it gets 'cloudy', then design until you get that FeelGoodFactor again. Now that is being Agile!
Previous Topic
