Enjoy the road
I’ve been really busy recently, which explains the complete absence of posts in the last few weeks. Between school and work, I don’t have much time left to write. I think it was last week, I was sitting in my formal methods class trying to figure out how OCL could be readable and watching demonstrations of various tools. At some point, I realized that all these tools were fun to watch, but they don’t bring that much value. Sitting down and scratching a piece of paper while thinking about the constraints in the system does a lot more ambiguity solving than using the tools. To use those tools, a lot of effort has to be placed on syntax issues, avoiding issues caused by the tool itself and incorporating elements that are not really part of the system just to make sure the simulation runs. You can guess I don’t really like resolving those issues.
Still, representing a system’s states as a diagram and writing down the invariants does raise some issues, but like most things, the time you spend working on the conceptual problems is worth a lot more than reaching the end. The same applies to many things in development. The time spent solving a complex problem is a lot more fun than watching the application run in the end (although it can be good when you spent too much time searching for the solution). The same also applies to estimation. You need to spend some time on it to reach those elements you would forget about. Simply counting function points and running them in the model simply won’t do any good.
Typing code is probably the only thing that can be done faster without loosing quality, but only if you live in a typo-free world.
Back when I was in San José, I think the middle part of the estimation is something I completely forgot about. Of course, with only 45 minutes, there are some elements you simply can’t cover. I realized it was not as clear as I thought very fast. The very first question I had to answer was about it and I had no material prepared and it’s not really the kind of topic that can be covered in two minutes and a half. The problem is that estimation relies a lot on analysis skills. I don’t think I even know how I do it, and it probably depends on the application domain. It’s all about sitting down and scratching paper. There are certainly a few questions I ask myself often to find hidden function points, but I never built a checklist for them. Where does the information come from? Can it be modified? In the same way for all users?
Of course, it all comes down to creating use cases and making sure all dependencies are met, but I hate having to write them down in detail, so I just take pages of notes with relations I won’t understand the next day. Writing things down clearly is like formalizing a model in OCL for checking. It takes a lot more time than it’s really worth. Especially when the goal is to perform an estimate. The goal is to know how long it will take before the project could have been finished. You’re better off spending more time thinking about the system than focusing on documentation. If the project is man-size, it’s probably not worth it to leave and maintain a paper trail. The only thing I keep is a list of all items with a function point count next to it. I don’t add much details, just with a few words so I can understand what they were all about. I either store it in a wiki or on paper. Nothing fancy. The only reason I keep it is to have a list of things I need to work on. This way, I don’t have to think about what I will do next. It has nothing to do with estimation.