Jobs and workflows

I have recently changed my job and there’s a lot to wrap my head around now. My new employer is about 250 times larger than my previous one, and apparently, there comes a lot of change with that size. For starters, I am now officially called a software architect. I did successfully complete a software architecture program in 2018 with my old employer, where I was also certified as a software architect, but my designation didn’t change, and I kept being an ordinary software developer. To be fair, this never even bothered me, since my job didn’t change at all with the certificate. If you work on client projects in a mid-size software house, you’re doing the full stack of the job anyway, and every one of your colleagues has to have the same wide skill set. Small companies have no need for dedicated software architects, test engineers, requirement engineers or documentation authors. In that world, you’re a software developer, and you can do it all, no questions asked. This is where I came from and where I’ve been living for the past seven years, and things were sweet and simple.

With my new job, there are about a hundred people in ten different roles, doing all the tasks that I used to do mostly alone. Obviously, there is a much more complex product behind this development process, and the pot of gold at the end of the rainbow is several magnitudes larger than what I’m used to. But it’s still a major change that will require some time to get used to. This acclimatization has been going on for three months, and I’m still getting most of my bearings. For example, the numbers I just gave are a complete estimate. I’m somewhat positive on the number of roles involved, but the number of people directly related to my work is really just guesswork at this point, and it could easily be five times as much. Because there is so much going on in my new job, I figured that it’s a good idea to map my new position into my previous workflow.

The way I create software

All this is a bit tricky, since I don’t have a clear definition of my current development process yet. There is a set of stages that I’m passing through during my workflow, but the exact order is highly dependent on the project itself. Depending on the current project settings and the customer’s wishes, some stages are reduced or omitted entirely. Tooling may also vary depending on the setting. Some customers prefer office applications for documentation, such as Word and Excel, while others go the more expensive route and invest in Enterprise Architect. I’ve once seen a ten meters long white wall covered in thousands of post-its, acting as a Kanban-board for a team of eight. Some teams use nothing but whiteboards, taking photos with their smartphones that are then saved to a network share.

But I’m getting ahead of myself. Because in the beginning, there is always a specification. Unless there isn’t, in which case I’ll have to create one by interviewing the customer and figuring out what they actually need. In many cases, this is the most frustrating stage of the entire workflow, even worse than figuring out those super sporadic and hard to debug failures that needed fixing yesterday. This easily ends up becoming a repeating event, until all those moving targets and vague descriptions are set in stone and the specification is finally done.

Once there, the result is used to create requirements and to analyse any risks that might appear. I have found that it works best when continuously moving back and forth between those two stages. After all, a found risk will likely introduce new requirements to mitigate the risk, while at the same time, a new requirement can introduce a new risk. It’s important to note, that a basic risk analysis should be done while creating the specification as well. Sometimes, customers tend to bite off more than they can chew, and having some risk analysis running in the back of your head can come in handy when it comes to budget planning and deadlines. The resulting requirements pour directly into the architecture definition of the software. I don’t usually do this in one go, I prefer to start with a very crude top-level design to get a first overview. The drill-down happens one piece at a time, where the architecture of a subsystem is defined and then all required APIs, contracts and corresponding unimplemented types are created directly in the code. As soon as the contracts are there, the previously created requirements and risks are translated into tests. If I did a good job, then every requirement and every risk can be represented by one or two test methods, giving very good test coverage from the get-go.

The previously created types have no implementation yet and are only there for the tests to compile. This is changing now, and the tests switch from red to green one by one, until the software is finally done. It’s not uncommon that I have to go back a few steps because I missed something earlier. Often these are just small steps, like adding a missing test during implementation. On rare occasions, I have to take a big leap backwards when something just didn’t work out as expected, like going back to the architecture design during implementation or even back to the specification, when something has gone horribly wrong. With all tests green and all requirements met, the customer is now putting the software through its paces. Meanwhile, I create any missing code documentation and manuals and finish off the entire paperwork. If the customer is satisfied, deployment is the last step to true happiness and my job is done.

As already mentioned, this isn’t always my true workflow on a project. Most customers play hard to get on specifications, trying to be as vague as possible. Documentation is another thing that is easily skipped, and many customers wish for no more than working code. This obviously means that any time spent on manuals and code documentation is wasted time, since it can’t be billed. But I draw the line when it comes to specifications, requirements and risks. Even if a customer explicitly does not want those, I’m going to write it down anyway, just a lot shorter but no less precise. I prefer to spend twenty hours on planning rather than a hundred on fixing bugs that the client found just before deployment. And let’s face it, fewer hours on the project mean less costs for the customer, which makes them happy, so there might be a follow-up project. I also tend to follow a test driven development approach, even if the customer didn’t request it. You simply can’t write working software without tests, especially if the software is supposed to work as expected. Again, this works in favour of a better product and less hassle for the customer.

How does my new position fit in?

With all that sorted out, my new job can be defined as a strict subset of my normal development workflow. The main focus is obviously the definition and maintenance of the architecture, with all the other stages being a problem for someone else. But even though there are dedicated roles for creating requirements and analysing risks, I’m still somewhat involved in that process.

I have nothing to do with specification, for which I am eternally grateful. All the other stages are outside my scope, but I do need to supervise and make sure, that things are done according to my architectural needs. For that matter, contracts must be defined as drawn out and implementations must satisfy all tests. There has to be a documentation and I should cross-check that from time to time, as well as make sure that the deployment works properly and the project isn’t stuck on pipeline issues.

But that’s only part of the truth, because I’m also responsible for prototyping new solutions. And that means going the whole nine yards for every proof of concept. That doesn’t mean that I’m back to where I started, where I’m still deeply involved in every stage. It just means that I get a break from my daily business now and then. This article hasn’t just helped me to understand my role with my new employer, it has also helped in understanding how I’ve gone around developing software products for the last years. Another thing it does is describing the differences in company size and how development is done in each.