How do you think about and architect programs?

Question

I'm a QA guy and designer and i'm coming to development. How do most developers architect programs? With design I build up with a vague idea of what I have in mind and adapt my design to keep in moving forward and looking good. With coding, I'm trying the same methodology. I'm constantly testing and debugging my code and I make forward moving tweaks to my code. The problem is, I dont think this is how it's done. When I look at good Javascript for example, everything is broken out into evenly distributed functions. I don't architect my code in this way. Do you normally have to sit out and draw out your classes and functions before you start writing?

Answer 1

Some devs architect their designs in UML completely before starting any coding, and others just jump right in. I've seen good designs both ways. The key is, I think, to be open to redesign and refactoring at any stage of development. A beautifully-architected design, conceived in a 300-page requirements document and drawn out with a stack of state and sequence diagrams, can be utter garbage when coded.

Be willing to throw out your work whenever necessary. Have the tests in place to prove that your refactored design works as correctly after changes as before. Having tests that you trust will give you the courage to change.

Answer 2

I think you should start to write code as soon as you have a clear view of how it will eventually be written, be it after 10 minutes of thought or after 10 days.
In order to achieve that you should use every tool at your disposal according to it's goal - I find mock-ups to be extremely helpful when I need to understand the reqs., database diagrams for designing the DB structure, and class diagrams for code (although that part I sometimes skip :-)).

Answer 3

The best definition I've come across so far for architecture goes something like this: When you learn how to read the time off a clock you've basically learned about its architecture. That there will be at least two needles -- a fat and short one denoting the hour and another thinner and longer denoting the minutes -- moving in a certain direction.

Design on the other hand is about how the clock actually looks and feels. Does it have all twelve hours etched on? Does it run on quartz or do you have to wind it everyday? Is it 10' tall or is it a wrist watch?

Implementation is about making the parts that make the design tick (pun unintended) that is the design sticks to the fundamental rules that our architecture laid down.

The Wikipedia article aside I suggest you go through the SEI website to learn more about software architecture. This article on IBM is a good start.

On the more practical side of things there are things called architectural patterns that significantly reduce the amount of effort you need to invest on defining an architecture when you start writing a brand new application.

Answer 4

Sometimes a prototype can be a really good way of finding out some possible ways of doing it wrong. Don't get attached to the prototype, don't worry about details unless it is a detail that will effect the overall system, just use it to understand the problem. Once you've had a good look at the problem you can either start a new prototype or if you think your basic design is right you can start a more detailed design process.