Category: Software Architect

Things are usually easier said than done, and software architects are notoriously good at coming up with things to say. To keep your words from becoming a lot of hot air (generally the key ingredient in making vaporware), you need a good team of developers to make it happen. The role of an architect is usually to impose constraints, but you also have the opportunity to be an enabler. To the extent your responsibilities allow, you should do everything possible to empower your developers.

Make sure developers have the tools they need. Tools shouldn’t be imposed on developers, they should be carefully chosen to make sure they are the right tools for the job at hand. Repetitive and mindless work should be automated wherever possible. Also, it is well worth the investment to make sure developers have top-notch machines to work with, adequate network bandwith and access to software, data and information necessary to carry out their work.

Make sure they have the skills they need. If training is required, make sure they get it. Invest in books and promote active discussions about technology. The work life of a developer should be hands-on and practical, but also should be actively academic. If you have the budget for it, send your team to technical presentations and conferences. If not, get them involved in technical mailing lists and look for free events in your city. As much as possible, participate in the developer selection process as well. Look for developers that are hungry to learn, that have that little “spark” that says they really dig technology (also make sure they can play ball with the team…). It’s hard to get a big bang out of a team of duds.

Let developers make their own decisions wherever it won’t contradict the overall goal of the software design. But put constraints where they count, not only to guarantee quality, but also to further empower developers. Create standards for the sake of consistency, but also to reduce the number of troublesome, insignificant decisions that aren’t part of the essential problem developers are solving. Create a clear roadmap for where to put their source files, what to call them, when to create new ones, and so on. This will save them time.

Lastly, protect developers from nonessential parts of their job. Too much paperwork, and too many office chores adds overhead and reduces their effectiveness. You (usually) aren’t a manager, but you can have influence on the processes surrounding software development. Whatever processes are used, make sure it is designed to remove obstacles, not increase them.

Every decision we make for our projects, be it technology, process or people related, can be a viewed as a form of investment. Investments come associated with a cost, which may or may not be monetary, and carry trust that they will eventually pay off. Our employers choose to offer us salaries in the hope that this investment will positively affect the outcome of their venture. We decide to follow a specific development methodology in the hope that it will make the team more productive. We choose to spend a month redesigning the physical architecture of an application in the belief that it will be beneficial in the long run.

One of the ways of measuring the success of investments is by rate of return, also known as return on investment (ROI). For example, “we anticipate that by spending more time writing tests we will have less bugs in our next production release”. The cost of the investment in this case is derived from the time spent writing tests. What we gain is the time saved from fixing bugs in the future, plus the satisfied customers experiencing better behaved software. Let’s assume that currently 10 out of 40 working hours in a week are spent fixing bugs. We estimate that by devoting 4 hours a week to testing we will reduce the amount of time spent on fixing bugs to 2 a week, effectively saving 8 hours to invest in something else. The anticipated ROI is 200%, equal to the 8 hours we save from bug fixing divided by the 4 hours we invest in testing.

Not everything need directly translate in monetary gains, but our investments should result in added value. If for our current project, time to market is essential to the stakeholders, maybe a bulletproof architecture which requires a lengthy up front design phase will not offer ROI as interesting as a swift alpha release. By quickly going live, we gain the ability to adapt to audience reactions that can form the deciding element to the future direction and success of the project, whereas not thoroughly planning can incur the cost of not being able to scale the application easily enough when the need arises. The ROI of each option can be determined by examining its costs and projected profits and can be used as a base for selection between what is available.

Consider thinking of architectural decisions as investments and take into account the associated rate of return, it is a useful approach for finding out how pragmatic or fit for purpose every option on the table is.