Development efficiency. The quick guide on how to kill It and how to save it

Importance of software

Software development quickly became the mainstream activity of specialized software houses and local development teams, within organizations, have been the norm for twenty or more years.

Now this is at the core of all current digital experiences within all industries as well as public sectors. The role and meaning of software development is only growing and will continue to do so through the next decades. The methods will change and the technologies will evolve, but most of the work will still be done by humans with the growing support of AI. Everything is becoming code, including data processing and infrastructure.

→ Explore our thoughts on Everything as code

Business demands more velocity, faster delivery, and the highest quality standards along with resiliency to ensure the competitiveness of its products and services in this digital era. Yet, despite so many lessons learned, and so many of them were very painful, managers tend to repeat the same mistakes over and over again.

This topic is very serious, but I’d like to turn it into an ironic quick guide for inefficiency first, then share some key findings on how to save ‘efficiency’ before it’s too late.

Quick guide for killing efficiency

Apply industrial era rules to software development

Some “clever” minds figured out that software development is basically a production of code and configuration that is translated for the user-facing functionality and interaction which is backed up by the APIs and data stores.

And then, after such enlightenment, they started to copy and paste concepts of efficiency from the industrial revolution into the 19th century.

In those times, the efficiency of workers was measured by the number of items they produced per hour or day. Then, quality requirements were added so only the items which were not defective were counted. Great for a factory that produces hammers or for a coal mine, so why not reuse it today? Because production is production after all.

Ok, let’s apply those rules to software development. What is the product of developers’ work? Code, definitely. So let’s measure it! Eureka!

This was the moment when someone started to measure lines of code generated per developer per day. Yes, those stories are true.

The next day smart developers started to add meaningless lines of code so as to fool the new system that was designed to control them just like if they were factory workers.

Some even measured how many key presses the developer did per day, for how long they were staring at the screen, etc. All of which could be easily faked as well with a little help from tools.

If someone starts a war with their developers, they have to know the consequences. They will get what they want and all is going to be officially green, but business users won’t get what they need in terms of quality and delivery times.

Time vs. estimation game, how to turn a win-win into a lose-lose

After the initial industrialization phase, waterfall methodologies for project management were all the rage. Project managers were using an infinite loop to manage projects. First, they asked developers how long the given functionality would take to implement, then they controlled the delivery time vs. estimation.

What did smart developers do this time? They started to overestimate the amount of work required in order to always be on the safe side, and to avoid unnecessarily and (sic!) unproductive discussions on why the given task was delayed. The “overestimate and code in peace” approach became the norm and is so until this day.

Project managers were happy about this too as all the tasks were green and on time. Some people (like me) beat their heads against the wall because they knew it could have been done twice, four-times, even ten times faster but nobody listened, because nobody really cared.  But of course, it’s impossible to have another project running in parallel in order to compare the results, so the unseen and uncomparable does not hurt too much, does it?

The same antipattern can be applied to agile methodologies using story points, for instance. The times are different but estimated vs. delivered often results in a natural response of … overestimation.

And overestimation is a great tool to achieve great levels of inefficiency.

More pressure on the development team

So let’s add more pressure on those lazy cheating developers so they keep to the deadlines. Let’s divide their estimates in half so as to avoid an overestimation of work.

But what if some of them, or even worse (in this case) most of them, estimated realistically and now the only thing left for them to do is to… cut corners.

And, this results in a huge spike of technical debt, which results in system instability, poor customer experience, weaker security, and regulatory risks all skyrocketing.

Forcing developers to do things faster and faster will result in a system that will be a so-called “ball of mud”, an unmanageable mess, and a source of frustration and embarrassment for the developers. Many of them will simply leave the company, moreover those who will stay will have to deal with a “minefield” full of traps and surprises slowing down the development pace even further.

Distractions kill productivity

Another very effective way to kill productivity is to provide as many distractions as possible. There’s nothing better than another meeting, another call, or another break in the flow.

Of course, a great way to ensure a constant flow of distractions is to put all the developers in one “production space”, factory style. It always “works”. The naive ones that are trying to focus on the actual task at hand will fight back with noise-canceling headphones and/or doing the most important tasks at home where and when they can focus. And, then they will search for a new job which will allow them to truly focus and have an actual impact, thus doing something productive.

The others who are less caring about the goals, will be happy with a constant flow of jokes, weekend stories, and short funny movies watched together and they will have tons of fun, thinking it is a great job. Add a salary raise based on “years of experience” and it’s almost a perfect workplace, at least until it goes out of business.

Let me briefly summarize this section with the example of a company trying to solve the issue of too many meetings with … a series of meetings to address the overwhelming hours spent on meetings each week.

In programming, this is called recursion.

Same project – different goals

Another common problem that is all too common is that many developers and DevOps have different goals than the actual goals of the project.

They’ve just read an interesting blog post and would like to try this new shiny technological thing in their project. They were promised that they would have time to do this in another, safe, and separated stream, but they know all too well that there’s always an excuse not to give them some breathing space to try new things.

So, the only thing that is left is to somehow bend the project towards the new shiny toy, creating an artificial problem that can be addressed with another tool. Another problem created? There’s another technology to address that as well. No need to worry. It’s just “barely” 80% of their workload going through the roof; our inefficiency strategy has a new ally.

People not doing anything at all

This is the ultimate leveler. I’d call it the Mount Everest of inefficiency. Empty commits or a lack of commits at all, adding space and removing spaces, and then working for another company by using the first one as just a hired desk space and laptop. This does happen as well, and it’s not as rare and as extreme as it sounds.

I still remember a project (external company asking for help) which I audited with a thousand man-days consumed and only three web forms were developed; unfortunately, two of them broke due to massive bugs.

This is often a consequence of the total disconnection of generic project/product management from the actual development work.

There’s an old saying that “code does not lie”, but so often managers don’t want to even take a look to see if there’s anything there at all there.

The modern form of this phenomenon is DevOps, which often turns into silos. And, what happens in those silos is often something that is making CTOs and CIOs dream of a NoOps future.

Quick guide for saving efficiency, probably

What? Why don’t I counterweight the ultimate inefficiency guide with the ultimate efficiency guide?

The reason is that the best practices have to be applied in the right context, with the right people, and at the right time. And, that’s something that cannot be simply described in a cookbook-style guide, ironic or not. You may think it’s not fair and I cannot disagree.

“Best effort” approach

Let people do the work and focus on the important milestones like the next sprint, release, etc. Do not micromanage, but instead motivate people to associate with the goals of the project. Give them the right tools and support, and they will do the job.

Show interest in the actual product of the work, be a part of the team and not an administrator, and then open the application, click it, feel it, and have some real ideas. Otherwise, they will perceive you as a useless and annoying administrator.

Most of the time this approach will result in the best outcome in terms of quality and time of delivery. But it’s very hard to swallow for many managers, because they are frustrated by the lack of control and they don’t know what to do with so much time at their disposal. Maybe another meeting?

“You cannot optimize what you cannot measure” is not true for digital product development because focus and motivation are much more important. The focus on the right thing at the right time and high motivation are the keys.

So management should let people work, sell their goals so the teams get on board, and show their engagement and real interest in the outcomes. The best digital experiences and products are created this way.

Let them focus on what matters

Removing distractions and unnecessary meetings, while letting people work from home or from a well-designed office, wherever they feel they can be more efficient, is the way to be proficient. And people are not the same, as one environment may work better than the other for different people.

All the activities related to analysis, design, architecture, implementation, testing, and deployment require focused attention. It’s often called “flow”, but if it’s broken by noise and interruptions then returning to this focused state will take a lot of time. This is one of the most common complaints that is very often ignored by managers without a technical background who don’t understand this type of job, and who are lacking empathy at the same time.

Goal alignment and personal motivation

Are my individual goals aligned with the business goals of the organization? How does this feature or technological change relate to the business success of the company? Does it all make any sense? What is my impact? What can I be proud of?

If there’s any doubt about any of those questions, there’s probably a focus problem and a motivation problem.

Knowing what we’re doing, why we are doing it, what is the impact, and what is the positive outcome for end-users, clients, and employees are the critical parts of selling the digital solution to … the internal team first.

Value streams

The state-of-the-art methodologies promote measuring progress with value streams. This is about tracking all the activities to business benefits for the organization.

If this particular feature and the code associated with it are not bringing any value to the customer experience, engagement, and efficiency for sales, it probably should not have been even done in the first place.

Does it sound like LEAN? Yes, but in a new form.

Removing waste is the key and the best first step.

The problem with this approach is that often one technical team activity relates to many goals with minimal impact. And… it’s easy not to notice any impact at all, but thousands of minimal impacts lost in this way may impair the entire digital solution.

So, the rule of thumb is to avoid tasks that are not leading to any goals at all and cannot be mapped to any, thus giving a chance to the others. Features can be tested using modern strategies including feature toggles.

Next steps

Despite using over two thousand words, I barely scratched the surface. I admit that honestly.

Real-world projects and digital programs will always require a dedicated and focused approach that is based not only on the best-known practices but, first of all, in the right context with the right people.

The truth is not in the middle, not at all.

The best approach today is the right combination of LEAN value-based streams, letting people do their jobs at work (focus), discarding the false prophets of agile, and selling the digital solution to your own team first (motivation, work that makes an impact). Take care of these and the customers will follow, attracted by the creative, secure, and well-performing digital experiences.