You may need an architect...to remedy the work of a worse programmer. Sometimes I recommend adding a software architect to a team, and sometimes I don't. My recent assignment makes me think about why you may need someone like me, a software architect.

A project is behind schedule and over budget. The team has run out of options. Management asks me to review the application and recommend a quick fix. A web application was built from "scratch" four months ago using technology both old and new. It sounds like it is a typical Internet-facing business application. For the record, let me just say that the existing source code is puzzling.

End-users complain of inconsistency. A fix introduces more bugs. I can understand why the programmer chose JavaScript. I cannot understand why all of the JavaScript is in-line; there is not one .js file. Nearly identical lines of JavaScript code are copied to two dozen pages.

A lead developer (or architect) establishes the proper way to maintain JavaScript code in a web application. She argues for an external JavaScript (.js) resource for common code. She demonstrates the benefits of building a common library to increase the consistency of the application and reduce defects. She insists on testing the application before installing it live on the Internet.

End-users complain of poor performance. The latest release is slower. I can understand why the programmer chose Java Server Faces (JSF). And yet, it is not really JSF! Code is written to undermine the JSF way of doing things. It actually fights against JSF.

The use of JSF is a far-reaching, architectural decision. Again, a lead developer (or architect) establishes the proper use of JSF. She is a mentor for embracing the JSF way of doing things. If JSF is not working for the team, she argues for something else.

End-users complain of surprising results. At one point, I could not believe my eyes. No, I thought, this is not possible. I stepped away from my computer. When I had cleared my mind, I looked at the source code again. Yes, the web application does not support multiple users! When generating a PDF, for example, the name of the file is a hard-coded constant. When two people run a report, the last one "wins". It fails most of the time. Beside the fact that one person accidentally sees another's data, the last report is viewable by anyone who has the URL.

Supporting multiple, simultaneous users is more difficult than supporting one user at a time. A lead developer (or architect) raises her concern when a design decision fails to support multiple users. She insists that test cases include scenarios for multiple users.

Behind schedule and over budget are symptoms. There is a problem the team cannot resolve. In my opinion, it lacks architecture. And it lacks architecture because no one was assigned the role of architect.