Software Industry – Sledgeworx Software

Agile has gone from ‘people over process’ to ’no process’

In practice ‘agile’ means ‘we have no process in place and each team does whatever random thing the manager wants to try next’. Sometimes that is SAFE sometimes its SCRUM, usually it’s a combination of different things. This isn’t necessarily a bad thing, but there are trade offs.

The first is standardization. If every team follows a different process it’s difficult to understand what is going on at a management level. Which teams are productive? Which teams are in downward spirals? If you don’t have a standard to judge against you can’t find out.

Secondly, away team work is much harder. Working with a team that uses the same development process, pipeline setup, programming language and frameworks is easy. On the other hand working in the code base for a team which uses a different language, framework, architecture, etc is very difficult. Not supporting away team work severely limits your ability to integrate internal software components.

Thirdly, Estimates are not possible in this kind of environment. Since the process changes constantly historical data becomes useless. In response to this most companies don’t even keep historical data. The main use for estimates is ensuring that ‘burn down’ charts follow the 45 degree angle managers love.

There is no team – Calibrating teams vs individual estimators

Subjective expert predictions are a valid form of estimating software tasks. But if you don’t have historical data to calibrate against estimates devolve into gaming the system.

When you change how estimates are made, when tickets are considered done and the sprint cadence every 3-6 months there is no way you can have cross company data on productivity. The lack of process empowers management to obfuscate the productivity of their teams. The pursuit of the best process gives technical organizations a great excuse as to why they have no idea if their processes have improved over the last two years or not.

In this type of environment all judgements have to be made based on subjective gut feelings and corporate politics. You don’t know which VP’s processes are better than the other because neither has any accountability. You don’t know which technical department is more efficient because neither the estimates or logged hours can be trusted.

‘We’re being agile’ has become the excuse to follow whatever process you want. Instead of ‘people over process’ it has become ‘no process’.

When creating processes (mechanisms) its important to consider who benefits

A business process is any procedure that is done manually by employees. In the software engineering environment this includes everything from code reviews to standup and 1 on 1s.

Compliance with processes involves education, incentives and punishments. People need to know about the process to follow it. And if you don’t attach incentives to the process, negative or positive, people won’t feel a need to follow it.

A common cycle I see is that management will think of a new process which could solve a problem the development organization is facing. They then declare the new process and are surprised when later on no one is following the new process.

When designing new processes it’s important to consider who benefits from the process. Additionally, it’s helpful to contrast who benefits with who is required to implement the process. Are the same people benefiting from the process as the people expected to implement the new process?

Your job as management is to create and enforce the business processes the team follows. Typically, this is best done with buy in from the team but the buck stops with middle and senior management. So it’s important to review what processes you tried to implement and how it went.

What pain points did we try to address with new manual processes this year? How clearly did we define the new process we wanted to implement? Did the team follow the process as expected? Who’s pain point did the new process address? Was it the development team? Was it the product team? Was it the management team?

Typically, people do not need incentives to follow processes which benefit them. But getting people to follow processes which do not benefit them is much more difficult.

Take the example of sprint burn down charts. These charts provide utility to project and management team members. But they rely on the engineering team members to update tickets consistently.

The conflict comes In because burn down charts provide zero benefit to engineers but all the work to support them has to be done by engineers.

This creates a dynamic where engineers are always incentivized to reduce their time commitment to updating tickets while management is frustrated that nobody is updating tickets.

You can of course make updating tickets the primary job task for engineers to fix this issue. But then instead of developing features, updating tickets becomes the primary job responsibility for the engineering team. Not what you want in a development organization.

The problem is that you have a fundamentally extractive business process. You need some group to take on extra work duties to improve the situation for another group. Having good reporting on the state of development tasks is an important thing for engineering organizations. But when designing processes to achieve that goal it is important to think about the process in the correct context.

Being one sided is not a bad thing in general. Businesses are fundamentally about generating profit. If we need an extractive process to make money then it is justified in the context of the business.

However, ideally we want to avoid these kinds of processes. We want to create processes which align the value produced with those doing the work. Because people enjoy following processes more when there is something in it for them. It makes their jobs easier and as a manger it makes your job easier because you don’t need to police whether people followed the process.

I’m excited to announce Sledgeconf 2023: architecture success stories.

For the next sledgeconf we will focus on software architecture success stories.

What does architecture success mean? Software architecture is the way we structure our software programs. A successful architecture enables us to support user requests, integrate improvements all while making it easy for the engineers working on the project.

A bad architecture has to fail in some major way. It might have simply not worked once it was built. It might have made it hard for maintainers to fix bugs. it might have been too expensive to operate.

They say that all happy families are alike, but at Sledgeconf 2023 we ask “Are all happy architectures alike?”

If you have a software architecture that worked that you be willing to speak on let us know! We are looking for speakers for Sledgeconf 2023!

Tentative date May 12th 2023

https://sledgeconf.dev

What makes a low tier software engineering culture?

In my conceptualization a low tier software engineering culture is one where engineers have low wages, low accountability, little responsibility and little control over the software development lifecycle. In my experience this is typically due to economic reasons more so than ineptitude.

One example is specification work for hardware integration projects. This article talks about how a culture of spec work killed the Japanese software industry for decades https://www.disruptingjapan.com/the-forgotten-mistake-that-killed-japans-software-industry/. These kinds of projects have inflexible deadlines, clear feature requirements and no customer flexibility. Customer’s can’t shop around for toaster software. The result is that engineers have little freedom or control over the software product. And since the software is merely a cost factor, little compensation is available for the developers.

Another example is the internet service provider industry. Companies like Comcast, Cox, Charter Communications hold regional monopolies over consumers. The software they build on isn’t the product and customers typically have no alternative source for internet. As a result around the 1990s most of these big cable companies outsourced their information technology departments.

These types of companies typically have little competitive pressures around the software they produce. The software just needs to work on average. You can’t shop around for a different operating system for your sedan. As long as the car works on average the software is good enough.

The problem is that these kinds of software culture provide very bad worst case scenarios. Take a look at this article on security vulnerabilities in automobiles https://samcurry.net/web-hackers-vs-the-auto-industry. Automobiles manufacturers as an industry seem to produce very bad outcomes in software.

The kinds of software engineering cultures that produce software that ‘merely works’ seem to produce software that is insecure, buggy and doesn’t ‘delight’ customers. But this is driven by business dynamics more so than teams or methodologies. Kia has no competitors in the market of software for Kia cars. You have no alternative to the software that operates your smart fridge.

Funnily enough there is a solution to this problem. Toasters, fridges and cars are all powered by general purpose computers. The same kinds of computers that we all use everyday. Just change the automobile into a platform that accepts an operating system. Just like any personal computer can be converted to any operating system you chose. Is that going to be easy? Probably not, but structurally there is little difference between your PC and the PC that runs your automobile.

Low tier engineering cultures are hard to fix. Due to the way the business works there is little money or freedom available to give to the engineering team. As a result skilled members of the team can easily move elsewhere and get paid significantly more. It is very hard to avoid a dead sea effect across the entire company and you end up with massive security issues like the automotive industry.

Please don’t learn software architecture off the internet

The internet isn’t the best place to learn software architecture. While you can quickly read about dozens of novel ways to structure software applications the internet tends to pull people towards poor solutions.

Software architectures are ways of structuring software to support various demands.

– development speed

– hardware platform (web, mobile, point of sale, drone, etc)

– team structure

– ability to scale aggressively (If we get a big customer can we scale 100x quickly)

– correctness (How often do we produce an incorrect result)

– recoverability (how quickly can we recover from failures)

– supporting a particular load range (100-300 request/second)

– software engineering team competency

The problem is that the internet talks about interesting architectures preferentially over appropriate architectures. If you learn about architectures on the internet you will hear primarily about solutions developed for global scale corporations. These corporations typically employ the highest paid, most experienced engineers on the market and have large operating margins to work with.

These ‘cool’ architectures typically support billions of operations per day and involve the efforts of 100s to 10,000s of engineers. Then the architect for a team of 20 engineers reads a blog post and decides we need ‘microservices’ or we need ‘event driven’. This sounds reasonable in a meeting. We ‘need to be able to scale if we get a big client’ sounds true. But it’s not.

People do not understand software scaling. To humans ‘one million records a day’ sounds like a lot. To computers that is only 11.5 records per second, something a single virtual machine running python can handle easily.

One million 10KB records per day is a problem you buy one hard drive per year to solve.

If you primarily learn about software architecture online your focus is driven towards optimal hyper scale solutions for hyper competent teams. Your team is not likely to be hyper scale or hyper competent. The ‘software best practice’ for normal teams is not the same as for google. Finding the appropriate software architecture for your company probably requires logging off and talking to experienced ‘enterprise’ engineers.