Empower Developers



Empower Developers

Timothy High

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 vapor- ware), you need a good team of developers. 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 develop- ers have top-notch machines to work with, adequate network bandwidth, 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 over- all 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 add overhead and reduce their effec- tiveness. You (usually) aren’t a manager, but you can have influence on the processes surrounding software development. Whatever processes are used, make sure they are designed to remove obstacles, not increase them.

Timothy High is a software architect with more than 15 years’ experience with web, multitiered client-server, and application-integration technologies. He is currently working as a software architect for Sakonnet Technologies, a leader in Energy Trading and Risk Management (ETRM) software.