A Starting Point for Fixing Systemic-Software-Development Problems
ExperTech Insights has been curating content through this newsletter, and it will continue to do so. Yet, this particular version is experimenting with a different focus. The attention of this iteration is on providing condensed answers to specific questions. The reply is the main attraction, while the content is the sideshow. Please read this miniature essay and subscribe, if you’re interested.
Picking a Place to Begin
An organization knows that it has a widespread issue. It has done an investigation and found the evidence. However, it does not know where to launch the correction of its problem. Underlying difficulties are complex. They are not going to be solved by an organization, in a single iteration. They are fixed, using specific techniques. Those approaches and a broader set of rules apply as much to struggles in application construction as they do to other domains. An institution attacks those struggles best, when it leverages its knowledge about institutional operations against its software development obstacles. The insight that applies most at the outset is to start with simple tasks that grease the path towards a larger solution.
A resolution to systemic problems might take a long time. A company could become weary, if it feels as though it is not making headway. Progress makes a long-term result more palatable. An end state feels more achievable, when a business is getting closer to it. Therefore, an organization should begin its journey, with baby steps.
The first stride is the salient question. That query is prone to analysis paralysis. Wrong moves result in rework, which wastes time. To avoid misspent resources, an institution exhaustively analyzes its options. Occasionally, it becomes so unsure of which choice to select that it becomes paralyzed. Yet, missteps are unavoidable, since uncertainty always exists. Therefore, a company should choose a small initial maneuver, one that allows it to adjust easily, if its journey is off course. That action is, ideally, one that makes future steps easier (or less difficult).
An organization should choose an opening salvo that is achievable and removes barriers to future corrections. That gambit involves priorities. An institution should determine whether its software development operations assign preferences to their work and whether those ranks are being followed. This maneuver can be implemented without affecting many other aspects. It merely seeks to adjust how future work is assigned, not what is currently chosen or how a company executes those tasks. A business should be able achieve this step. If it does not have or enforce priorities in application construction, then it will struggle to overcome other difficulties in that area. The assignment of preferences and their enforcement are an attainable opening-shot that eliminates barriers to other fixes.
This step should be guided by an organization’s expertise from its other operations. That company likely prioritizes its work in different domains. It probably sticks to them, and it presumably punishes those who do not abide by its priorities. An institution should use its experience with setting up and carrying out preferences to guide its implementation of a similar scheme, in software development. Programming needs to rank its work, just as every other area of a business does.
That organization can prioritize a software development task, using a formula, expertise, or reading the entrails of goats. The specific mechanism does not matter initially as much the existence of a prioritization strategy. An approach allows company to correct its priorities. With well-chosen preferences, an institution can move to fixing other issues. The problem of ranking out work begins with the step of having a scheme for doing so and actually following it.
That maneuver and the larger problem involve more details than this newsletter provides. It does not intend to wrestle with them. Those knotty matters are handled in the Software Construction Journal. Its pieces are more comprehensive than this entry is. They are designed to provide, in some total, a fuller body of knowledge. This item is merely an appetizer, a Cliffs Notes to more detailed pieces.
Curated Content and Authors
Daniel Bryant, Holly Cummins, Eran Stiller, and Thomas Betts discuss current architecture and design trends.
Gary McGraw describes risk analysis in software development.
Ben Linders and Casey Rosenthal talk about how chaos engineering's facilitation of learning helps organizations handle complexity.
Mike Cohn argues that story points should not be equated to hours.
Ben Linders, Eberhard Hechler, and Thomas Schaeck mediate on how an org can use AI in activities it already does such as DevOps.
Jesse Trucks discusses strategies for moving a legacy application to the cloud.
David Choe talks about the cost of spending too much time monitoring progress and not enough doing planning.
Alex Diaconu describes the validity of assumptions made about distributed systems.
We wrote an article that argues complex software problems should be solved, using the same techniques other areas use.
We published a piece that describes the architecture of a strategy and the process for building one.
Titus Winters has PhD in Computer Science from the University of California, Riverside. He is a senior staff software engineer at Google, specializing in API design, maintainability, and large scale changes.
Wrap-up
Subscribe, if you found this discussion or content useful. Read Software Development Journal and Strategy Construction Journal for more in-depth treatments of the subjects handled here. Follow ExperTech Insights to get content as it is distributed.