My design process
Vijay Santhanam asks about the design process I takes for building:
How much analysis/OO modeling you do before you start writing real code? With tools like R#/SVN is the up-front design pretty much dead for garage projects?
My answer to that is complex. I don't do design. I don't think that I ever had. What I would do is something I call envisioning. I have posted several such things in the past, most recently it was Architecting Twitter.
A good way of describing that is this picture:
I am not really interested in the entire picture. I am interested in very small key parts of it. This foundation is what the entire application will revolve around. Very rarely I'll sit and try to draw out the entire system up front. And each and every time that I tried to do that I have had good reasons to regret it.
Once I identified the shape of the system, I I can start working on it. But the final result tend to be different than even the vague shape that I had at the beginning. I routinely modify the foundation of the system for the first part of the project, until it stable enough to fit what I want it to do comfortably.
I like to use tests and real use cases as the driving forces for this. A good sample of that can be seen with Rhino Security. I envisioned the system several months months before I actually wrote that, and while many of the high level concepts were retained, a lot of the infrastructure was shifted, as I faced real world constraints and had to solve them.
I'm the same way. I do tend to grab the old pencil and paper and scribble my notes and arrows, etc... :)
Totally agreed. I've been working really hard during my current project to get the guys working under me used to hearing and saying the terms "just-in-time design" and "just-in-time architecture" and to not fear the frequent (though less and less severe as time goes on) and inevitable changes that result from requirement and design insights that are gained along the way. Reminding them that every change in understanding results in a change in code, warning about being an "astronaut", reinforcing the last responsible moment principle, all sorts of things. The resulting difference in attitude, energy level, and success of the team when compared to others in the building is remarkable.
This is close to what I see, although I usually have a concept of the whole thing at a very high level as well. I tend to have today's architecture stored with what I think the goal architecture should be. I use a lot of visualization in my head.
I am always reminded of (and still fascinated with) Tesla and the Mind Lab. Nikola Tesla used visualization (among other things) to take the blueprint of a system, build it, and start running it in his mind. Then weeks or months later would check back on the the system running in his mind to see where the wear and tear was!
“Before I put a sketch on paper, the whole idea is worked out mentally. In my mind I change the construction, make improvements, and even operate the device. Without ever having drawn a sketch I can give the measurements of all parts to workmen, and when completed all these parts will fit, just as certainly as though I had made the actual drawings. It is immaterial to me whether I run my machine in my mind or test it in my shop. The inventions I have conceived in this way have always worked. In thirty years there has not been a single exception. My first electric motor, the vacuum wireless light, my turbine engine and many other devices have all been developed in exactly this way.” - Nikola Tesla
Like I said, I am fascinated with his concepts! I don't know what truth there is to Tesla's abilities, but I can say that visualizing things in your mind really helps. I have trained my mind to go back and forth from the 10,000 foot view to what a certain piece would look like. I tend to think about things for weeks and how they will fit together. With that I can say I am probably pretty strange. Maybe in a good way?
All of this sounds like design to me, but it's good to know you're a rapid prototyper oren.