Author: jeffrfinn February 23, 2015 1 Comment

Hmm, where to start. This is a topic that occasionally makes me feel lost. As a project develops I sometime find myself second guessing my previous decisions. Why did I chose this, what was I thinking when I wrote that class. It’s easy to dismiss this as someone else’s job, but that’s just not right. As developers I feel that we should be able to think about design decisions independently and anticipate potential pitfalls. Architects should be used for guidance rather than to provide explicit instruction. I want to talk about a few areas I consider to be key in software architecture.

Plan before you start

You are starting a new project, you’re excited and you want to jump straight in. Stop, don’t ! Take time to read and understand the requirements if they’re available, otherwise  write up a short requirements document maybe between 6 – 12 pages for a small project. Then review it with everybody who is involved in the project. Iron out any ambiguities and differences in terminology. Now you’re ready to begin planning.

Once you understand what is being asked of you, start planning the application. Does it need a Web API? What types of data am I storing? Who / where will it be used ? When does it need to be done by? Theses are just a small set of questions that you should be asking yourself / your team. Every project is different and there will be different questions for each project. The point is to think about the project and come up with a suitable architecture that will fit the projects needs.

Draw and model

Real architects spend a lot of time drawing and modelling a building before it gets built. We should do this too. Draw out how you want the application to look and leave it somewhere that it is easy for the team to view. A visual diagram is a really good way of describing the overall view of the application, break it down into it’s general components spread across the different layers of your project. The point is that all of the development team understand it. It should be easy for anyone to view and to modify. It is important not to view this as gospel and to keep it as a continuously evolving document.

Some people might be saying sure I don’t need that I’m working on my own and I can keep track of it myself. I was like this, I’ve a pretty good memory but I have been working for over a year as a single developer on a reasonably big project and to be honest, if I take a break from a project I find it difficult to get back to where I was and into the mindset I was last in when working on it. Keeping a visual representation is an easy and quick way to remind yourself of what you were doing and where you planned on going.

Model things before you write. If you are trying to explore something write a quick throw away piece of code to try and evaluate the idea. Once you start trying to code an idea you will quickly realise some of the ideas benefits or downfalls. Doing this will allow you to decide between different solutions that look the same on paper.

Understand your decisions

When you start making decisions, understand them and their potential consequences. Try to come up with more than one solution and quickly compare them with pros / cons on a sheet of paper. Some ideas you will immediately know are bad, but compare them anyway. They will help highlight the benefits of the other solutions.

Don’t use a technology just because it is new, if you decide to use new technologies remember that it will take longer to get started and for you to become proficient with it. Don’t just decide to use what you already know, it may not be the best solution available and you will never get the opportunity to learn new technologies. I’ve just listed 2 pretty big dont’s, what should you do ? Look at the project. If you have a lot of time available, look at trying something new, if you need to show a demo quickly it might be better to start off with something you are familiar with, saying that if you are a C# .Net developer and you are asked to quickly write an iOS app you will probably have to step outside your comfort zone right from the beginning.

What I’m trying to say is understand why you chose to do something and to constantly evaluate possible solutions. Just because it worked for you before doesn’t mean that it is the best solution now. Technology keeps moving and offering new solutions to problems. The point is to think about what you need. It might even be worth while to keep note of your design decisions, especially if you are working on projects that might drag on for a while.

Think ahead

One of the things I see a lot about Agile development is to solve the immediate problem and not to try and anticipate what else the code will be used for in the future.

I’ve seen this go very badly and caused us to smash the DRY principle into tiny little pieces that all looked the same. This happened in a MVC .Net application. We had a repository layer that held our code to communicate with the database. We had a lot of very similar calls that solved the problem at the time and returned the exact information that was required. With a little more foresight and experience we should have written the first query use parameters to decide what was returned. This process continued without thought until one day I was looking over the code for areas to re-factor and I noticed all these repository methods that were very similar. At that stage it was too late, they were too widely used and the effort to fix it was too great to fit in with the timeline.

The point of this is don’t take things literally at the expense of good design. Think about what you are doing, keep your code flexible and extensible and before you start abiding by something make sure you understand it. What I now know is that solving the immediate problem means don’t write methods that you don’t need right now, but don’t leave it up to others to make your method usable for their needs. Keep your code as flexible as you can within reason.

Don’t fear change

You could have spent a lot of time designing and modelling your application, if that’s what you needed to understand it that’s fine but don’t spend longer than you need to. The reason why, is that it will change. Never get too attached too your design. Sure you can be proud of it but let others see it and be prepared to let them change it. Other people will have better ideas than you, the best solution will be something that you work on with your team.

When the project matures this will also cause your design to change. The sign of a good design is that it can change without too much effort.

Keep up to date

We touched on this earlier, but don’t fall into the pitfall of using what you know. Look at what is happening outside of your immediate team. Spend time looking at what others are doing in the industry, look to other industries and see what’s happening there. If it’s suitable for what your doing try to use it. Try and keep on top of new technologies and understand how they may or may not benefit you. Continuous improvement is something we should always be working on.

What I want from an Architect

If it’s up to the developer to do all this, what is left for the architect ? This is what I want from an architect. When I work with an architect I want them to provide guidance and be involved with the design. I don’t want them to dictate what we use or how the application is used. As developers we should suggest technologies that might be suitable to the architect. The architect should evaluate the technology before providing guidance or an alternative solution. There is a danger that with a week architect, they might accept what you say without looking into it, or that if they are not actively involved in development they might fall behind on the latest development trends. Falling behind on the latest trends might cause them to be resistant to change and favour sticking with technologies that they are familiar with.

The main requirements for an architect is for them to be clear when communicating and to listen to the development team without making presumptions. They should never muddy the water when discussing the project and at the end of the discussion the project should be in a better place and everyone should understand the solution that was decided on.