Time to Wear a Lot of Hats

OK, maybe just a few hats... I see some of us enjoy fashion more than others. And that's just fine.

The modern software developer - especially those in high demand in today's modern job markets - are able to wear a lot of different hats. And that with a bit of style.

There are three hats we'll find ourselves wearing the most:

• Analyst
• Engineer
• Architect

An Analyst?

Yes. An analyst. We must be able to analyze our problems and decompose the problem into its simplest components. How do we this?

We iteratively remove unnecessary complexity in our quest to state our problem in the simplest possible way. Because simple problems have simple answers.

And, more often than not, any seemingly complex problem can be decomposed into smaller problems - or "features" - that are easier and simpler to solve. When we use all of our smaller units of functionality, we can compose our solution from the toolbox of "features" we've implemented in our software.

Here's a real world example:

As a manager of an accounting department, I want to generate a report showing paid time off usage by department so that the management teams can anticipate whether or not we need additional hires.

Whoa. That seems like a really big problem!

But let's break the story down into individual units of work with their own clearly defined inputs and outputs:

• Create a report that calculates PTO per employee.
• Create a collection of employees grouped by department (say, everyone in IT)
• Create an automated process to run the PTO report for each individual in the department and save the results.
• Create an automated process to collect and summarize the data from the previous step.
• Present the report data in a form determined by the business users' well-defined acceptance criteria.

Now that we've analyzed our problem into its coarse components, we are ready to try on a new hat.

And it just so happens we're very stylish.

An Engineer?

Yes. An engineer. Engineers take plans and schematics and create working technology. Sometimes, the plans come from an architect, but often, the engineer has a lot of control over their own creativity.

The best engineers have a wide view of the problem domain and the business cost of their decisions.

• "Sure, we can use MySQL, but here's where we'll need to scale horizontally and vertically."
• "Yes, we can rewrite our monolith into a collection of microservices, but here are the pros and cons and their related business benefits and costs."
• "Definitely. We can move to Kubernetes. Here's how we'll save in ongoing operating expenses and here's our initial capital investment to fund the project of transforming a small datacenter into federated Kubernetes clusters. For this project, and the granularity of the required cluster access controls, we should purchase OpenShift licenses from Redhat."
• "Yes, we can do vanilla Kubernetes - here's the tooling we need to create for ourselves and here's the cost to make a less polished version of the vendor offering, and look, our version would be significantly more expensive to build and deploy, and that process is more expensive than the integration with our vendor."
• Etc., etc., etc.

An Architect?

Yes. An architect. Especially in a team environment without a person or team specifically dedicated to the architecture of the project.

But what is a Software Architect?

Just like a traditional architect designs a building, so does a software architect design and supervise the construction of a software project.

Typically, an architect will provide guidance on what we should be building, how to building, and specifically the high-level design of the system components and sub-systems.