With all due respect -- that is just how some of us work internally. We learn by experimentation, intuition and repetition.
I often find it extremely difficult to write a design document for a system, particularly a system owned by somebody else. I have written design documents in the past, and they rarely end up describing the eventual system, no matter how hard I work to maintain and update them.
In my experience, software design and engineering is an iterative process, like gradually groping in the dark to determine the shape of a room. I cannot simply turn on the lights and take a photograph of the room at the start of the project.
Having said that, I completely agree that in principle it is great to start new projects with a complete design document, at least a functional specification. Accurate technical specifications are a rare, elusive beast, though.
If you don't know what you're trying to build, you probably aren't going to manage to build it. But in practice, you never actually know for sure, because things always change.
You should know how you're going to build it (the architecture). But in practice, my ability to be omniscient is very limited. As I implement it, I find out that my design/architecture was wrong.
Maybe the key factor is this: When you find out that the architecture is wrong, do you fix it? Or do you just hack it to get the next bit to work?
> When you find out that the architecture is wrong, do you fix it? Or do you just hack it to get the next bit to work?
That's very project and organization dependent. Some projects are short lived prototypes (I'm working on one now) that are for internal use only, so it makes sense to try and get the damn thing finished without worrying too much about architecture.
Other projects are built to last, or have very high quality requirements, so you want to really get the architecture right, even if that means costly rewrites.
(Reading this a few days later in an open tab. :-) )
Imho the most important thing is to have a good design document for the data model. Partly because it often decides a lot of the structure of the code.
It is e.g. easier to rewrite code than realize that you lack some stuff you should have captured about customers years ago...
I often find it extremely difficult to write a design document for a system, particularly a system owned by somebody else. I have written design documents in the past, and they rarely end up describing the eventual system, no matter how hard I work to maintain and update them.
In my experience, software design and engineering is an iterative process, like gradually groping in the dark to determine the shape of a room. I cannot simply turn on the lights and take a photograph of the room at the start of the project.
Having said that, I completely agree that in principle it is great to start new projects with a complete design document, at least a functional specification. Accurate technical specifications are a rare, elusive beast, though.