My 10 Principles for Software Architecture and Design.
In my current position as a Software Architect I work daily to design software that meets specific business requirements. I am also new to my current company and the style of the other architects differ slightly from my own. So, feeling a need to define what "my" principles of software architecture are so I could verbalize them easily, I decided to create this post. Here they are.
1. Stick to the defined requirements. Never design for tomorrow.
In the world we live in the requirements for business functionality in a software system change daily. A requirement today may or may not exist in it's current form tomorrow so there is no need to guess what functionality may be needed tomorrow. Of course, good software design accounts for things like scalability and other predictable changes.
2. Design software for the user.
The end goal of business software is to provide the user with a tool to do something they either could not do before or to do something more efficiently than they could do it without the software. If, by designing a software system, you make the user of that system less efficient you have failed.
3. Simplicity!!!
If a software system is overly complex it has been designed wrong! I am a firm believer that there is a simple solution for nearly every problem.
4. Expect and embrace change.
Has anyone ever designed software based on requirements that never change? If so take a look at principle number 2!
5. Delivery high quality, scaleable, readable, maintainable code.
This one should be self explanatory.
6. Testing!
Whether or not you implement some sort of test driven development, testing your design as well as your code is a requirement. You can not accomplish principle number 2 by allowing your users to find a majority of your bugs and design flaws.
7. Make Decisions!!!
To many times I have been involved in projects where, what to me, seems like a simple 5 minute discussion turns into weeks worth of meetings to make a simple decisions. Make the decision and if it turns out to be the wrong one then change it and get back on track. I would rather make a bad decision then no decision at all.
8. Calendar based project management always fails.
How many times have you been told that you need to design, develop and implement a solution by Y date without regard for the amount of work or resource requirements involved? There are three sides to the software design triangle. Time & Money, Quality and Scope. The customer gets to control 2 of these sides but you as the architect or designer get to control the third. In my experience I have found, almost always, that the customer tries to control all 3. They want full scope, delivered high quality for X dollars by Y date. If the customer wants full scope delivered high quality then I get to determine the deadline. If they want to stick to a budget and delivery by a certain date then I determine the scope.
9. Collaboration and Communication.
The majority of the software projects I have worked on that were successful had all the stake holders identified and dedicated to the project. With everyone needed for the project available it makes principle number 7 easy.
10. Enjoy what you do!
If you stop enjoying your work, then stop doing it and find something you do enjoy! Life is way to short.
These are just my personal principles in no particular order. I think everyone, no matter what there career, should define what their principles are for doing their job.
(Theo Johnny)