I have been interviewing people on software design. I cant even remember in how many interviews candidates jump into designing the data layer as soon as the requirements of the software are provided. Only a magician can do this right.
A normal engineer needs to think top down. The data layer is the foundation of the system. Go to the foundation in the very end.
You start with a requirements and start defining functional blocks of your product. Think of it like different parts of machine, say if I were to design a car, i would think of the engine, the AC, the body, the seating etc as the “functional blocks” which are directly derived from the requirements.
These components need to be able to interact with each other to make the software you need. You can call this a “High Level Functional Components Diagram”.
Once you have this diagram ready, ONLY then you should get into the design of each of these components.
Take a look at this nice article on a structured design thinking and different perspectives which are important in a design process – http://bit.ly/aXGVAd
Is it really so hard to understand this 1 simple thing ?
Here is my 6 point definition of “Dirt Mode” software development which suits developing new SAAS based products. This is a practical software development style and in some way supports the lean software development principles.
Use a pluggable and adaptive design (adaptable to alternatives in technology). Dont integrate with any one particular technology too deeply.
Don’t try to create a “sophisticated” design / architecture. Keep it simple and lean. Assume that you are going to throw it away the next quarter.
Build no automation tests and write bare minimum UTs just for your own confidence on the code. You know that you may end up throwing the technology you are using, and adopt a completely new one. Take a look at one of my earlier posts to see why it makes sense.
Use Test Driven Development like technique – don’t write automated tests, but create a detailed test plan before writing code. Spend time review these test plans more than the code. This would ensure that the code delivered in the first go is high quality with few surprises. You would save a lot of time in code reviews.
Be crazy about measuring software quality and success after launch. You know that there would be surprises. If you get to see issues in the way it works today, be more than ready to throw away / re-factor any of your components and do a quick re-write (instead of trying to hammer the same thing too much). If you miss this one, it would be too late for you to do a re-write / throw away when your customers start telling you how buggy your product is. So you should know how you plan to check if you software is working as it is expected to in the live environment before it becomes a big issue for your customers and your business.
Be very careful about what technology you choose for your product. Relying on the latest may seem cool and fashionable but in my experience its a very risky thing to do un-less 1) you are developing this product just for the fun of it and you mean to make no serious impact OR 2) You are doing it for experimentation mostly for RnD. Try to use more mature technologies which have plenty of adoption and support.
Once you get a feeling that the design and technology choices you had made are reasonably right which would happen after a few iterations depending on your initial attempt(s) , you can then start putting in the the heavy-weight stuff like automated tests, extensive UTs, hardening the design by integrating with the technology capabilities more deeply.
Also, the point #6 only makes sense when you have a variety of choices. If you are building something that depends on the latest technology that was released yesterday, you have no choice. Take the plunge !
These are my thoughts, I would love to hear yours. Please share your opinions in the comments section.