Project Documentation Redux

A couple of weeks ago, I wrote about how I love documentation and how useful it can be in the future, for you or someone else. I also lamented slightly about how it is hard on most projects to get the time to write good reference documentation. This week, I'm going to discuss one possible way to knock out some of the more time-consuming parts.

The key word is: Design. That is--the "Design" phase of the project. In most projects, regardless of the flavor of SDLC utilized, there is a block of time to be utilized for designing the solution. Since this is work that will be happening anyway, getting some good documentation out of it is simply a matter of writing down what gets discussed, decisions that get made (along with the "why"s, of course), and how the solution(s) will be structured. Chances are these things get written down, anyway, but outside the mindset of their possible use as future reference material. Usually, by its nature, designing a project will produce some useful artifacts; things like high-level architecture diagrams or possibly an ERD or two. If it's a data-integration or BI project, and one is into details, source-to-target mappings are likely generated at this point.

All of these items add up to a decent set of notes for the future, explaining the solution and where it came from. This way, even if no dedicated time can be worked into a project for documentation, useful items can be produced.

I think there's another benefit to this course of action. I have a phrase I use to describe my philosophy on this topic: I don't like to think while I'm writing ETL. This sounds kind of bad on the surface, but what I really mean is this: When it comes time to actually sling some code, I want to be able to concentrate on the mechanical details; Things like doing everything right, following best practices, security concerns, and making things as highly-performing as they can be, all right from the get-go. With the data flows already drawn out and the business rules documented and agreed upon, it is easy to focus on those things.

We had a fairly nice conversation about it being hard to get the time to write documentation when I wrote about it before. Would beefing up the efforts during the design phase help? Are ya'll even able to get good time for the design stage in the first place (I've been in predicaments where that gets axed, too)?

Parents
  • Right, that's true...writing things as "design" means that it needs to be maintained as the project goes along, because everything always changes. There isn't, unfortunately, always time for that.

    I'm a big proponent of mumbling in OneNote as things go along, whether I'm solo on a project or working on a team. That said, this doesn't always lead to the most organized pile of text, and that means (in my experience), it has an even less chance than normal of getting read emoticons_sad.png

Comment
  • Right, that's true...writing things as "design" means that it needs to be maintained as the project goes along, because everything always changes. There isn't, unfortunately, always time for that.

    I'm a big proponent of mumbling in OneNote as things go along, whether I'm solo on a project or working on a team. That said, this doesn't always lead to the most organized pile of text, and that means (in my experience), it has an even less chance than normal of getting read emoticons_sad.png

Children
No Data
Thwack - Symbolize TM, R, and C