Craig Pardey

QA organisations have come a long way in the last decade or two. In the early 2000s, automated unit testing was just gaining popularity and QA was performed manually by armies of testers. The QA process was time-consuming and arduous, and the testing timelines were the first thing to be compressed when development took longer than planned (as it almost always did).

By the 2010s, many applications had moved to a web interface which allowed QA teams to automate some or all of the end-to-end testing using Selenium, or similar. This was a giant leap forward, especially for basic 3-tier apps with a web UI, a “services layer”, and a database. Everything was nicely contained in the one codebase, including the tests. Coupled with Cruise Control Hudson Jenkins, we had a reliable way to delivery quality software quickly.

What is it like to work at your company? Think about it carefully. How do your people spend their time? What culture and behaviours do you incentivize? Is it a good place to work?

Culture in this context describes how people interact at work, the processes and policies, productivity friction, meeting efficiency, et cetera. Your company’s culture describes what it is like to work for your company, and it has an outsized impact on the type of people your company is able to attract and retain, and whether they feel productive at work.

I’m working for a client that has separate teams for architecture and engineering. Architecture is responsible for defining the long-term direction of the platform and engineering is responsible making that dream a reality, in addition to their day-to-day sprint work. Each engineering pod has a representative from architecture as one of its members but their role is mostly about producing documents and interfacing between the two teams - they don’t touch the code at all.

Before COVID-19 and ubiquitous work-from-home, we used to have meetings in a room where people would sit around and discuss the matter at hand. The start time had some flexibility because people had to physically move from one location to another, often between floors or buildings. Whiteboards helped focus the conversation. People could interject organically without having to raise a hand like in grade school.

Unplanned conversations in the office were common and often more productive than a formal meeting. I recall bouncing problems and ideas off people from other teams while waiting for the kettle to boil, and they’d offer thoughts based on their experience. The cross-polination provided valuable perspective.

The backend-for-frontend (BFF) pattern is when a backend API is designed specifically for the needs of a frontend consumer. The BFF is intended to make frontend development simple, moving all the complexity and “business logic” to the backend and allowing the frontend to deal with a single backend. The backend BFF API closely resembles the flows and screen designs of the frontend.

The initial development experience is often positive. The frontend team can focus on the UI/UX aspects of the application, and the backend team can handle all the downstream integrations and data transformations.

Consider the following statement:

Our consultancy operates on a 50% margin.

Margin is how much extra the consultancy charges on top of their costs to cover the consultancy’s costs, operating expenses, and profits. Most consultancies have a minimum margin that they’ll consider acceptable when bidding on work.

But the details matter when it comes to requirements. A lot. The statement above is subtly ambiguous. How is margin calculated, precisely? I can think of two ways which make sense but result in wildly different profits for the consultancy.

Documentation is one of the most valuable artifacts of any technology project or platform. It provides context to new joiners, avoids duplicating responses via Slack/Teams, and facilitates asynchronous communication, but it also requires constant care and feeding.

Confluence is where documentation goes to die
– Unknown

Most of the large enterprises that I’ve worked for have a large corpus of documentation in a wiki of some sort. Most of it is dangerously out-of-date, incomplete, duplicated, and fragmented across different pages or spaces. Documentation of this kind causes countless wasted hours and frustration on the part of the reader. There’s nothing worse than spending days working through a documented process only to discover that you’re following an outdated copy because only wiki admins can delete pages.

New technologies generate a lot of noise as they work their way through the hype cycle and it’s hard for newcomers to figure out what they should learn. Only a small number of these new technologies will survive the test of time, most will be forgotton, but the FOMO is real.

While there’s value in the process of learning the new hotness, I think you’ll see a higher lifetime return when you invest in learning the basic tools of the trade - the skills that you’ll use day in and day out, and skills that will transfer well from one job to the next.

One thing that development teams constantly struggle with is striking a balance between building features, fixing bugs, paying down tech debt, and embarking on more ambitious activities like replacing core components in their architecture. It’s also something that Agile tries to solve but I’ve never seen it solved to everyone’s satisfaction.

And I think it’s because many Agile Product Owners are focused on the specifics of what features they’d like to see built instead of setting the direction for the dev team and letting them figure out how to get there. They allocate some random percentage of the sprint to tech debt just to keep the team happy but it’s hard to make significant changes with 10% of the sprint capacity.

Software should do one thing, and do it well. Each piece of software should have a clearly-stated goal that is used to determine whether a particular feature should be implemented or not. When a proposed feature does not fit with the software’s stated goal then don’t implemented it. Just don’t.

Like adding source control to your product. We already have several perfectly good source control systems. Building your own custom source control system into your product is never a good idea. Your implementation is unlikely to be as good as the standalone products like Git, Mercurial or Subversion, and it’ll probably make it difficult for me to use my source control system of choice.