and maintainer of:
I just finished first draft of a my input to a technical design document.
I would very much like to be more into agile development methods, but the place where I am working currently is using a process to control projects, which is more a waterfall model.
At the same time the model is lacking or circumventing itself in so many points, that it almost is ridiculous.
Well anyway, I have been involved in these input processes for a few projects now - and I can see severe problems in the process and these seem to be related to organization.
The online team with is located in marketing (which is a good thing), is under the Marketing/Sales division, the technical projects are run and are primarily controlled in the Technology division. So the technical specifications often totally lack the online aspect and input. The systems involved in the online part are only mentioned by URL. Sometimes with a few screen shots or very broad requirements.
It struck me at some point that this lack of focus on the online aspect has two sides.
1. The lack of specification detail, gives the online team totally free hands. then again they would have this anyway, but that is due to the holes in the model
2. The lack of specification detail, leaves the online team to not be regarded as a serious part of the technology of the system. This mean that resource problems and workload are parameters are not communicated to the rest of the organization via the formal channels
But things work anyway... due to the employees
The currently used model has holes and in the end everything ends up being very pragmatic, this introduces problems with resources and workload, but still things get done, late and at a very high cost, again due to the model.
So what I have done for now is implementing an approach I have used in my own company. I write a synopsis as input to the technical specification. This synopsis is a work document, it lives for as long at the project/work package is active and it contains requirements, issues, issue log, references, recommendations, estimate and basic component architecture.
This document can be used to outsource the assignment to other developers, but myself - for now I have only written the synopsis for assignments given to my company, which mean that we provide the necessary resources and I take on the assignment and communicate it to a hired resource.
The synopsis also serves another purpose, it gives me an understanding of what it is the client wants.
I am not much for doing a complete design of an application, since I want the developer assigned to the task to be free to implement as he/she sees fit, just adhering to the requirements and general best practice.
Which reminds me, I really, really want to write a developer handbook for the client, describing the framework in use and so on. It would save me a lot of explaining if I could just reference this document.
Okay, so some of the hackers I am working with and are hiring, tend to think that documentation like this is over-doing it.
My synopsis approach addresses several problems as I see it:
It breaks down the problem area and raises issue for unclear parts, before we start coding
It serves as decision log for closed issues so we can read why we did as we did, even the bad decisions, or especially the bad decisions, which might have been good decisions at the time
It provides a more solid base for estimates (something I for one is not particularly good at)
We can read the synopsis when the application described need to adapt new business requirements and start a new synopsis for that project
The resources I hire will turn to me the moment they run into a problem, which they cannot handle, so the synopsis helps me to respond to that, instead of just headlessly outsourcing assignment, not knowing they contents
Large organizations have the memory of a goldfish - The memory is with the people and people get busy or find new jobs or go on holiday
Hackers have memories like goldfish, they cannot remember what and why they did something in some code late one night 3 months ago (the business guy told me to)
So yes white boards are nice, stand-up meetings are nice but these all have to make place for other things eventually. Email is nice, but it is often unorganized and it is good for communication not for reference.
Yes we can read through the code, but nothing parses better for the human brain than prose with a few pictures.