Posted On: 2020-07-27
A key part of my development cycle (both in my current project and my previous work) is finding ways to improve development efficiency. The exact motivation for these improvements varies somewhat*, but in general the goal to improve efficiency is both self-motivated and value-building. This is important, as it makes improved efficiency a natural consequence of trying to do a good job - something which, itself, is central to being a good developer.
Before one can improve efficiency, however, one needs to be able to detect the inefficiency/imperfection of existing tools/processes/systems. Without detecting a problem, it can be extremely hard to know what to solve (or that there is anything to solve in the first place.) Fortunately, there are a number of simple tricks that can be used to try to detect inefficiencies that might otherwise slip under the radar. In this post, I'll go through a few that I have personally used - and some examples of how to implement them through team collaboration.
The first, and simplest, way to detect an inefficiency is to be impatient. If you want results now, then anything that gets in the way of that becomes an inefficiency. While this comes relatively naturally for me*, someone who is naturally very patient can simulate this by having a stakeholder/user providing immediate/realtime feedback. If the stakeholder is themselves impatient, that can often be enough to make one aware when things are going slowly, but even if they aren't, the act of showing others can help to draw attention to places where there are lulls in activity - or steps that seem extraneous and need some additional explanation/justification for why they are necessary.
Despite its simplicity, being impatient does have some downsides as far as consistency of detection. The primary one is distraction creating bias: if an inefficiency happens when one is distracted (such as thinking about which test plan to use) it will be less likely that it will be caught. Additionally, impatience can mis-identify legitimate development efforts as inefficiencies - with planning and testing often flagged erroneously by the over-impatient.
Familiarity can habituate one to the quirks, issues, and inefficiencies of one's tools. First-time users of development tools can often spot issues/obtuse processes that more familiar users simply take for granted. This means that, when joining a team that uses different tools, one can immediately provide value by detecting inefficiencies that the team may have overlooked. Even if the team doesn't have time to address those inefficiencies now*, it can be useful to document these, for reference when the opportunities do arise.
For those that aren't (themselves) newbies to the relevant tools/processes, it can still be relatively simple to gather that new perspective. Anytime someone new is added to the team, they will bring some amount of new perspective*. By positioning oneself to be closely involved in training/on-boarding the new team member, one can be well positioned to use that new perspective to discover inefficiencies that were otherwise overlooked. When in such a position, it is especially important to keep an open mind about things: the newbie perspective wears off with time, so making the most of it may require silencing the instinct to say things like "this is just is how we do it."
Taking one's skills at detecting systemic flaws in software designs, and applying that to find systemic flaws in development processes can be a tremendous boon*. Analyzing the mental model one uses to represent development tasks is generally helpful, as is analyzing design of existing tools - to understand what kinds of models they afford. Comparing those models (mental model and tools' models) can often reveal mismatches between them - places where one is unconsciously using workarounds to bridge the gaps between the two. Such workarounds are often inefficiencies that can be improved through changes to tools and/or processes**.
Like with any analysis of user expectations and/or systems, it can be quite helpful to collaborate with teammates. In many cases, teammates are also users of the same tools, which can make collaboration even more valuable. Finally, if a particular developer has difficulty with such analyses, working together with a team can be an excellent way to make sure that person's experience/perspectives can contribute towards finding inefficiencies.
Above all, the most important element to detecting inefficiencies is the belief that things can be better than they currently are. This attitude is essential, as it creates the bridge between recognizing when something is inefficient, and doing something about it. Without such a bridge, one may misdiagnose inefficiencies as unchangeable, reclassifying them to be unavoidable problems rather than inefficiencies to clear up.
Unfortunately, this is often the hardest part of solving inefficiencies. Technical familiarity is often necessary to know when a relevant tool can be (programatically) customized/remixed to make things better. Policies and processes are often change resistant, and they may influence or obstruct efforts to do things better. Lastly, competing attitudes/cultures (such as a defeatist culture) can crowd out or stifle optimism.
If one finds themselves having difficulty staying optimistic about being able to execute changes, it often is helpful to collaborate with optimistic, emotionally supportive people. Optimisim can be contagious, particularly between people who trust each other - thus, having people who understand one's goal and genuinely believe it is possible can be a massive boon for acquiring the requisite disposition to improve things.
Identifying development inefficiencies is an important part of effective software development - and the first step on the road to solving them. There are many different approaches to help identify them, and many of those approaches can be executed even if this individual involved doesn't have the disposition/background necessary to have it occur naturally.
The optimism to believe that something can be done to resolve (at least some) of the inefficiencies is likewise necessary. While this can be difficult, it is a necessary step in solving the inefficiencies - and (in many cases) well worth the effort.