April 23, 2005

...Learn TDD with Codemanship

Process != UML != Documentation

There's plenty of confusion and mythology out there about UML and modeling in general that I thought I should address and hopefully do my bit to set the record straight.

First of all, I work with a lot of consultants who know everything there is to know about analysis and design, but fail to appreciate that this is just a small part of the software development process. There's a lot more to delivering software than that. There's configuration management, there's testing and other forms of QA, there's project management - estimating, planning, tracking, resourcing, budgeting, and so on. Then there's the actual development of the code - which many UML enthusiasts tend to gloss over (possibly because they don't write code themselves any more). In the grand scheme of things, UML and modeling is just a small - but important - piece of the jigsaw. You can't deliver working code through OOA/D alone (not yet, anyway...)

I can understand the battle that's been raging between the modeling community and the agile development community. Agile developers appreciate the importance of delivering something that works, and modeling stops far short of that. It's not that eXtreme Programmers don't see the point in using visual models. It's just that they, and I include myself in this to some degree, feel that OOA/D and UML often takes on too much significance in a lot of projects - especially projects that are dominated by analysts and architects and other people who don't deliver working code.

In many OO projects, the models become an end in themselves, and I've seen projects where there were more people working on them than were working on code. Inevitably, the models become huge and crammed full of unnecessary and often flawed detail. Ultimately, the developers - who can easily get sidelined in this kind of approach - end up building something quite unconnected with the model. Who got it right? Is the model the definitive answer, or the code? My money's on the code, because once it's delivered and has been accepted, who cares what's in the model?

I'm not a huge fan of employing specialists to do modeling. Firstly because I've yet to meet a died-in-the-wool analyst or designer who was better at OOA/D than a developer who does their own analysis and design. Secondly because project managers feel the need to keep them busy right through the project, so they end up doing a lot more analysis and design than was probably needed. Misguidedly, many managers mistake keeping people busy with getting value for money. Hence we can end up with 50-page use cases and enough diagrams to wallpaper an entire office block. Most of this stuff never gets read - who has the time? And most of it is of little use in taking the design forward to a working system, possibly because the modeler doesn't appreciate what a programmer needs to get the job done.

So, I urge you not to confuse OOA/D and modeling with a software development process. There's more to get right, and ultimately you need to focus on activities that move you forward to working code. I've lost count of the number of projects I've witnessed in which the developers were sat around scratching their heads while the analysts and designers kept themselves busy producing models nobody needed.

The second point I wanted to make is about the connection that many people have in their mind between UML and documentation. Indeed, I get frustrated by the mantra that documentation = quality, and that you can improve a piece of software by documenting it. You can't. Documentation has little or no practical effect on the code we deliver. Undoubtedly, useful documentation can help people to learn how to use an application, or give people a bird's eye view of the architecture. But it's value is limited, and anything with limited value should have limited time and effort invested in it. In other words, you need to do the absolute bare minimum of documentation possible - that's not to say that you should do no documentation at all, but keep a very close eye on the benefits you're getting from documentation when deciding how much to invest in creating it.

What ticks me off is the way in which many people see UML as a documenting tool. With that mindset, we produce models that are about as useful as JavaDoc (and if you've ever spent hours on the Internet looking for help with a Java API, only to end up screaming "but how do I use it!!!???", you'll know what I mean). OOA/D is NOT about producing documentation. It is a thinking and problem solving process that takes you from functional requirements to object oriented code. Once the code is delivered, just how valuable are the models you created? They reflect your thought processes during analysis and design - they show your working, but they are not the actual solution. You may want to keep a record of how you got to the solution you did, so you can apply that knowledge to similar problems, but at best that just means keeping an archive of your UML diagrams like a scientist keeps a lab diary. (Indeed, I strongly recommend keeping a diary - you'd be amazed at how many problems you solve in the average project that may come up again.)

But the myth persist that process = UML = documentation on many projects. Perhaps on yours?
Posted 16 years, 1 month ago on April 23, 2005