I’ve always held the opinion that there is a significant difference between a Programmer and a Software Engineer. This plays specifically into the capabilities of someone writing code, as well as the hiring process for a particular position, and the responsibilities a company is looking for in a job candidate. Sometimes in a small company, a single individual is expected to wear all of the hats, whereas large enterprise companies may separate out the responsibilities into several different roles.
Let’s look at each of the roles a little closer and investigate why companies should strive to have Software Engineers that can DO architecture.
Note in this post “Architect” and “Architecture” refers to the person responsible for the planning of your technical project at a high level of operations and execution.
A Programmer is someone who can write code, understands the concepts of logic control, looping, functions, etc. Perhaps this person builds websites, and maybe database driven applications and various utilities. Typically, however, the code produced may be more of a collection of scripts than a complete software package. Sometimes the code produced by a programmer may be short on some industry best practices, but that may or may not be important for the role this individual serves. In many cases, junior professionals join a software engineering group as a “programmer.”
The Software Engineer
A Software Engineer is a programmer that has expertise in developing software effectivley and efficiently. They apply a formal structured approach to software development thinking about correctness, completeness, reusability and maintainability. When solving a problem, the Software Engineer doesn’t just write code that satisfies the feature request. Instead, there is problem decomposition, planning, testing, coordination, etc. It’s not just a question of whether the problem was solved, but rather how well it was solved, and how efficient and maintainable the solution is.
The Software Architect
A Software Architect typically is tasked with thinking about and planning the structure and interactions of a software at a high level. Typicially this person is a seasoned and experienced Software Engineer who understands the best practices of how sustainable long lasting software can and should be built. The Software Architect may be tasked with the theoretical design of a software system, integrating various design patterns and development principles to architect a solution to a particular programming problem. Perhaps the Architect is given the software requirements and then produces a set of diagrams and charts, and maybe even some initial code representing the software foundation, but the Architect typically gives that output to a group of Software Engineers and/or Programmers to use as a plan for building the actual implementation.
The Problem & Solution
In terms of building long lasting, mission critical software, you’d typically want to enlist the talents of one or more Software Engineers to create the system and ensure its long term success. Perhaps the development team consists of several Software Engineers and a Software Architect. The Architect produces the plans and the Engineers build it.
Often you find that a particular solution was created by an Architect and delivered to engineering, but as time goes on and the software grows, some pieces of the plan are not implemented fully for one reason or another. More time passes, the software evolves and is extended, until one day there is an issue that blocks development progress due to lack of architecture or a breakdown in the implementation.
You see, as engineers we are problem solvers; we get things done. When an engineer comes to a point where the solution requires building something outside of the architectural plan, a decision must be made as to whether the Architect needs to be re-engaged to examine how it should be built. Maybe the engineer thinks: “Nah, I can do this, it isn’t a big deal,” and builds a solution that they believe solves the problem. In that moment, a small amount of “technical debt” was taken on, and as time passes the situation could repeat itself until the result becomes a problem and breaks down progress.
The engineer in the previous example wasn’t being careless or cavalier, he just doesn’t know what he doesn’t know. Unless the Software Architect is re-engaged periodically to review what is being built, the adherence to the architecture plan can’t really be enforced and extended as needed. On the other hand, if the Architect must be constantly re-engaged, he becomes a bottleneck in the production process.
In conclusion, knowledge of architecture is essential to successful software development, but it could be argued that a Software Architect is usually considered a senior role, and it’s not feasible to create teams primarily composed of senior people. The solution to this problem is to have all Software Engineers know about architecture.
Having engineers who are able to navigate architectural issues, and not having to engage an architect on every possible architecture change, creates a more workable model. Educating engineers on architecture as much as possible seems to be the most sensible middle ground.