Ok, this is not about technical issues I usually write about. But this again is an issue we all (technical folks) face time to time and have to deal with. Recently, at my work place, I heard about a project that has not been meeting deadlines and people dreaded to get into. The reason why that project was not able to deliver was blamed completely on the very "complex" architecture and just that. I have heard and seen this so many times that I always wonder, can projects really fail just because of a complex architecture? Is it just the architect who has the final call on how the product/project would be designed and build? Is he/she not just providing guidance and is it not upto the technical leads to guide the developers and the architect on what can be delivered by looking at the resources available and timelines set for the project? How can no one see that the architecture is complex when they in still in the design phase and later blame it for the failure after working on it for couple of months or years?
Back when I was introduced to programming and when I used to write code in dbase and Foxpro (some of you might have not even heard about these languages), my approach to tackle a requirements would be to just start writing the code. Given a task, I would start writing the code without really thinking on maintenance or trying to understand the whole picture. But I soon realized my mistakes when I saw my efforts been spend on writing the same piece of code more than once or trying to fit a change that the users suddenly felt is very urgent and should be part of the release. That is when I started appreciating the need for a good design and the need to spend more time designing than just writing code. Now that was easy when I was the designer and the developer on the project. But as I moved onto bigger projects and teams, I realized that this approach of investing time on a good design was never accepted with open arms. But somehow I managed to work through my deliverables and thought when I become the person who leads these projects, I will give more importance to the design :-)
So what exactly do we mean by design or a software architecture. Is it just drawing couple of colorful boxes to link them up with some lines or is there more things that an architect needs to consider. Based on my experience, here are “some” of the important items that I feel affects the design of any software application.
Team dynamics
When I started managing teams and be responsible for the deliverables of some developers, I realized there are other aspects to this whole process. I started understanding the fact that in most of the cases, your "team" is the not the best that you would like to have. 70% to 80% members in your team does not see or care for your vision. Many do not know how to code and some are forced into this project that they never wanted to move into and some others are there just because its part of their “job” and does not care about quality. So now I had to adjust my vision and beliefs again. I realized that the team structure is also a factor you need to consider while designing. In the .Net world, imagine you designing a SOA application and developers have never heard of such an approach and you hardly have time to explain and teach. Yes, a good developer will be able to grasp and develop under any circumstances if given proper guidance. But remember the 70-80% I talked above earlier.Time
That brings us to another topic that always affects your design - Time. Time is always a factor to what you can deliver. Most of the time, in a practical world, (I think you would agree too) that all projects you work on had to be delivered even before you started the work. So I learned the hard way that you are always behind schedule and will always be trying to meet unrealiastic deadlines. That usually meant that you have to take shortcuts that would eventually mean more defects and so more time to fix. So its better to manage your time efficiently and to spend it on the most important modules. For me, the most important and easy to design modules in any project are the common libraries that will be used by other modules. If you design them well, you would realize that you have more time to spend on other core functionalities and building them around these common libraries is pretty easy.Common libraries
That brings me to the next point which is that all good architect must also be responsible to identify the common features or libraries that can be reused. In all projects, things like exception handlers, data access, logging, etc are always needed. Unfortunately most of the time, these are the features that are considered to be least important. So the end result is that the application has no proper error handlers or logging and when the application encounters errors, there is no information available to debug. You also face the risk that each developer might handle exception differently (or will not even handle them) and some errors might be reported more than once and in different ways. This could even affect your user's experience.Templates
Once the common libraries are taken care of, what to do with other modules and how to fit them in to ensure easy maintenance and ease of writing code for your developers? It can done using templates .. What I mean by templates is just a default structure of how a class or a function or object would be coded for. Most of the applications we develop are for services that require data to be input by users, saved and retrieved. If you have proper structure or template of how data would be managed and flow between various layers, the developer’s responsibility would reside in just reusing these templates and filling the gaps with properties relevant to that module or web page or form. I have seen that if you have properly commented templates defined on how these items in various layers would be coded for and also explained the process to developers on how to fill the gaps, development is much easier and faster. Also this ensures that all modules follow the same "style" of coding and its easier to maintain. This way a developer coding for a particular module can easily pick up other items in some other module and not have to spend too much time trying to figure out how it is coded.Performance
This is one of the key factors that most of the architects seem to forget i.e how would the application perform under heavy load. I have seen time and time again, performance is something that is always tackled after couple of months into production release because that is when real users start pumping in data and the screens or pages that used to respond in milliseconds now takes minutes to show results. So someone reviews the code for reasons of slow response and most of the times, it’s the architecture to blame. Now its too late or too expensive to fix these performance issues because that would mean re-designing most of the things that you just released.Technical leads
How can all the above be managed? Is this all just the responsibility of the architect? I have seen time and again that most of the architects feel that their responsibility lies in drawing pretty diagrams that explain the architecture using visio or some other tool. When you have to finally translate those diagrams into working code, many of these architects cannot help or would not like to help. So its left up to the Technical leads to translate those design to code and explain the process to their developers. For that task to be done efficiently and effectively, you need good technical leads. If you get some good ones, you can always rely on them to manage the team the right way. They can help the developers whenever they are stuck in some tricky situation, review code and ensure that the architecture is followed and distribute work according to the strength of each of members.So what exactly works? Is it all of the above for every project? I would think a combination of all of the above does ensure a successful project. But unfortunately its an ideal scenario and you have to pick and choose what can work for you. Try your best to concentrate on these points and I would think you can deliver a successful project. Yes, this is not the complete list. There are lot of other things that can affect a project like how requirements are documented, QA assigned to project, availability of resources, etc. But this article was just to highlight what I think are the key items you need to keep in mind while planning.
