- Use the simplest tools?
- Simplicity enables agility
- When should you use CASE tools?
One of the most commonly asked questions asked by developers is “What tool(s) should we use?” Although there are as many answers to this question as people asking it, I would like to provide a few words of advice to help guide you: “Use the simplest tools possible.” Why simple toolsSimple tools are easy to learn, easy to use, and very often easy to share with others. Yes, complex tools have their place, assuming they provide the best value for your investment in them, but never underestimate the effectiveness of simple tools either.
Some simple tools for modeling:
- Index cards. The eXtreme Programming (XP) community swears by the use of standard index cards for a wide variety of modeling techniques, and in particular Class Responsibility Collaborator (CRC) modeling.
- Post-It notes. Post-It notes are also an option for you, for example you can develop an abstract/essential user interface prototype using Post-Its on large sheets of paper. This is part of a technique called essential user interface modeling, described in Software For Use by Larry Constantine and Lucy Lockwood or my own The Object Primer 3/e.
- Paper. Pieces of paper, or index cards, tacked onto a whiteboard and connected by strings can be used for a wide variety of models. For example the individual sheets of paper can represent database tables and the lines relationships between tables on a physical data model, or the sheets can represent screens and the strings navigation flows between screens on a user interface flow diagram, or the sheets can represent use cases and actors and the strings represent associations between them on a UML use case diagram.
- Plain old whiteboards (POWs). A whiteboard for sketching on is likely the most common modeling tool in use. A digital camera can easily make copies of sketches that you want to keep.
Why simple tools for modeling? I always advise that you should ask yourself why you are modeling, my philosophy being that you should develop something with an exact purpose in mind otherwise you shouldn’t develop. If you are modeling to understand something then the value isn’t in the model that you create but in the modeling itself. Therefore, you don’t need to invest significant effort using a CASE tool to make your model look pretty, or to add comprehensive documentation to it. Instead you’re better off using a simple tool, such as index cards or a whiteboard, to enable you to get your modeling done quickly so you can get back to developing software. More importantly, when you also adopt simple techniques you discover that your models are inclusive for your stakeholders, enabling active stakeholder participation.
When should you use simple tools? My rule of thumb is that the greater the amount of uncertainty surrounding the issue that you are modeling the greater the flexibility you will want in your tools, therefore the simpler your tools need to be. As you gain a greater understanding of an issue you can migrate to more complicated tools as required, assuming that the tools provide the best value possible for your investment in their usage, typically starting with manual tools such as index cards or white boards and eventually moving to a design CASE tool or programming IDE.
For example, when I am first exploring how I intend to build a screen I will often use Post-It notes, sticking them to the nearest flat surface (a desktop, a whiteboard, and so on) that I can find. Post-Its are easy to work with, you can write brief descriptions on them or little sketches, and easy to move around. Furthermore they stay where you put them because of the glue on their backside. Post-Its are great at the beginning of screen design because you can get a feel for the layout very quickly, adding and removing widgets quickly.
Once I’m happy with the layout I’ll either move straight to coding the screen or to the whiteboard. I base this decision on my initial purpose for developing the screen layout model in the first place. If my goal was to simply get a strategy for organizing the major widgets that will make up the screen then I’ve very likely satisfied that purpose and can therefore move on. If my goal is to determine how I will organize the screen and to identify the widgets that I intend to use then I will very likely move to a whiteboard first. With a whiteboard I can draw the widgets with greater accuracy, drawing them to their relative size as reasonable facsimiles of the actual type of widget (check box, single-line entry field, multiple-line entry field, “¦). However, whiteboards aren’t as flexible as Post-Its – if I discover that I need to move several widgets then I may have a lot of erasing and redrawing with a whiteboard, whereas with Post-Its I simply move them around. The observation is that I the gain in fidelity by moving to a whiteboard was counter-acted by a loss in agility.
Once I’m happy with the whiteboard drawing the purpose for developing the model would once again determine my next step. If I was simply modeling to understand the design of the screen then I would go straight to code. However, if I was modeling to communicate, perhaps my organization’s process insists on the development of detailed screen specifications before any coding can begin (clearly not a very agile process) then that would be my next step. Actually my next step would very like to be to fight this tooth and nail, but fighting the bureaucrats within your organization is another issue entirely. If I am forced to create comprehensive documentation I’ll likely use a CASE tool that specializes in the type of documentation that I’m trying to create, in this case a screen specification. As an aside, an important lesson to take away from this discussion is that models are not necessarily documents – I would consider both the Post-It notes and the whiteboard sketches to be models, likely ones I will discard.
Why not jump straight to code? First, code isn’t as flexible as either Post-Its or whiteboard sketches, I can’t move things around as easily as I can with Post-It notes and I very likely can’t change widget types as easily as I can sketch. In short, I suspect that a few minutes working with Post-It notes and possible drawing some sketches will very likely pay for itself several times over in saved coding time. Second, Post-Its and sketches are more inclusive than code, non-developers such as my direct users can become actively involved with the effort which makes a lot of sense to me because we’re working on something they can directly relate to (the user interface).
On the surface it is easy to assume that if you’re an agile modeler that you aren’t going to use a CASE tool. Poppycock! An agile modeler uses a tool, any tool, when that tool makes the most sense for that situation. Just like a carpenter will use a manual screwdriver sometimes and other times a electric screwdriver, sometimes an agile modeler will use an index card and other times a complex software design tool.
Any tool, including Computer Aided System Engineering (CASE) tools, should be used only when it is the option that provides the maximal value for your investment in it. This is basic investment theory – if you can invest your money one way and get a 10% overall return, or you can invest your money another way and get a 15% overall return, everything else being equal you’re better off with the second investment. With respect to modeling tools, you always have several choices: use simple tools such as index cards and white boards, use a diagramming tool such as Microsoft Visio, or a more complicated tool such as Compuware’s OptimalJ, Borland’s Together, Rational System Architect, or Computer Associate’s ERWin.
So how do you calculate the expected value for your investment in a tool? I suggest that you don’t, at least not from in strict accounting sense of the idea. Yes, you could prepare a complex spreadsheet listing all the costs, both quantitative costs that have a clear dollar value and qualitative costs that need to be fudged into a dollar value, and then compare them with the expected benefits, both quantitative and qualitative. You’d naturally have to calculate the net present value (NPV) of all of those figures to ensure that you’re comparing apples to apples. I’ve got a pretty good write-up of how to do all this in my book Process Patterns if you’re really interested, but I highly suggest against this sort of lengthy analysis. Why? Because it’s a lot of work that is more often than not a faÃ§ade used to justify a political decision anyway.
- Initial training and education
- Evaluation costs
- Maintenance of the model over time (it’s even worse when the model has outlasted its usefulness but you’re still maintaining it for posterity)
- Upgrade costs of the tool
- Ongoing usage/maintenance fees
- Time lost waiting for the tool to do its job
- Time lost over-using the tool (e.g. making your diagrams look pretty, extraneous information, and so on)
- Migration costs to port models to another tool
- Increased effort to synchronize models with other artifacts, such as source code
- CASE tools often promote syntax over communication between developers (in other words, your model looks good but doesn’t necessarily work)
- Generated code often too simplistic, or cluttered with extraneous information required by the tool
- Poor user interfaces often hamper the modeling effort
- Inadequate integration with other tools reduces productivity and/or requires integration work
- Complex tools are often prevent the inclusion of non-developers in your modeling efforts
- Forward engineering (code generation)
- Reverse engineering of existing code
- Support for changing levels of abstraction (e.g. from requirements to analysis to design to code)
- Testing of the consistency and validity of your models
- Synchronization of models with delivered code
- Support for different views and/or potential solutions to a problem
- Generation of documentation
The principle Model With a Purpose tells you that you should know why you are creating an artifact. Knowing the purpose for an artifact indicates the extent of the work that you need to perform to complete your model, you stop as soon as your model fulfills its purpose, and this in turn provides insight into what you require of your tools. By knowing your actual requirements you can then determine whether a given tool will actually provide the most value for your situation. My experience is that a gut-feel approach to choosing your tools is often the most effective approach, albeit one that senior management may not trust you to take. Furthermore, you should know the features of the tools that you are using, and the practice Use the Simplest Tools tells you to select the most simple tool (even if it’s a CASE tool) that will do the job.
Consider some examples:
- You are modeling simply to explore the potential structure of several Java classes. You clearly need a tool that supports class diagramming and perhaps supports generation of Java code. My two best options would likely be a whiteboard, I would sketch the classes and then proceed to write code, or Together/J, I would use the tool to diagram the classes and then generate the code from the diagram. My deciding factor would be how well I know Together/J and how likely is it that I would need to work with the tool in the future – If I know the tool well or it was likely that I would be doing enough Java development in the future to warrant my learning the tool, then Together/J would be a good choice for me because one of its primary strength is its support for Java developers.
- You are developing the table structure for a database. Yes, you could choose to sketch the schema on a whiteboard and then start coding the data definition language (DDL) code to create those tables, and the procedural code for any triggers, but that’s a lot of work. Several CASE tools exist, Computer Associate’s ERWin is one, that supports the ability to generate the DDL and triggers automatically from a data model. Once again, the deciding factors are skill with the tool and whether it is worth the investment to learn the tool.
- Your organization has won a bid to identify and document the requirements for a system, with the hope that you will win the next stage of the initiative (the actual development itself). Ignoring the dysfunctional aspects of the serial nature of this approach, the reality is that many teams still work this way. In this situation I would be tempted to use a variety of tools – a Word Processor for textual information, a tool that supports creation of use case diagrams, and perhaps even a tool to manage the requirements.