‘Design Plans’ for Product Implementation
A couple of months ago I started asking my team for ideas on content that would be helpful and meaningful to an audience of military members and peers in the defense world. Low and behold, the first person to respond was one of our longest tenured software engineers and technical implementation experts, Ryan. In a previous career he was also a geologist and civil engineer that worked on evaluating and measuring things like the status of infrastructure like dams and bridges. In our economy, people with engineering skills gravitate to all kinds of jobs, and many end up in software for a variety of economic or personal reasons.
With that in mind, this is mostly second-hand research and observation by an engineer supporting the Department of Defense today. The context and story belongs to my peer, with some flare and creativity inserted by yours truly.
Setting the Stage
Who else remembers the old bridge building computer game? A user selects the type of material and you can put a span here, choosing things like length and track things like weight and cost. For those of you that welcome the distraction, here’s a version of the game. Ryan has a quotation that explains the theme of this topic.
Engineers do not invent a bridge every time they need to cross a river.
The point here is that there are a defined subset of bridges. Off-hand there are maybe half a dozen, well defined bridge types used. These various types of bridges are selected based on the scenario — a suspension bridge here, a truss bridge there, even a place and a time where a rope bridge may make sense. When a civil engineer is facing this question, they do not start from scratch, inventing a new bridge type with novel materials and bring in an architect to paint with a new brush. If, instead, engineers did not exist, written word, communication, and we had to start with a novel approach to bridge building, how many bridge solutions do you suspect we might have? How many of those would be viable versus some hack used for a single purpose? How could you predict whether or not the bridge would function or fail?
Design Plans
In Agile development, innovation and invention are often a part of life. Building software carries a lot of unknowns, and many use cases are, no kidding, the first time someone has built that solution. There is necessity and value in these innovations. In practice, many engineers deemphasize codifying solutions that are spawned by said innovation. Sometimes that is a product of time and resources, others it is a necessity to protect intellectual property. Also, in practice, it is less common for tasks or epics to be issued by project or product managers that enable deliberation about using an existing design plan or making a now educated decision to innovate. For those building in Waterfall methodologies, it is probably even worse with a more rigid structure for building pre-defined solutions. Personally, my magic eight ball tells me to try again when I try to predict much more than a few weeks into the future. Change is just a fact of life, and we are doing our best to keep up with demanding pace and moving targets.
Part of this is a learning curve that junior resources often need first-hand experience to grow. Ryan was once a junior engineer. What do junior engineers (and non-engineers) do? They make mistakes. Some of them seem so bone headed with the benefit of years of experience, years where we often made the same mistake — and sometimes more than once. In some cases junior engineers get relatively ‘simple’ tasks, for example a low story point ticket that is estimated as a one or three. That task might take this resource significantly longer than anticipated. The day they have their shiny unicorn code developed and head bravely into a code or functional review, a senior engineer might point out the lunacy of their approach. Ryan says it using variables:
Why did you invent X when you could have done Y? Y is so much less effort.
Oops. The junior engineer probably thought it was a good idea at the time. In fairness, we should not expect them to share the breadth of knowledge earned through wading through these experiences. The good news is the experience is not a total waste, and the engineer also invented the known, which means they will better understand the underlying purpose. Chances that the solution is a better, more resilient one are low, but experience is earned as a badge of honor.
Now, minor improvements to effectiveness while adding efficiency can be put into place. The original task might have mentioned the potential solution, the junior engineer would then have at least a flashlight to guide them through the dark. It might also justify and validate the original story point estimate. In fairness, junior resources often need more guidance than their more senior counterparts. Even senior resources can fall trap to this issue from time to time, we’re all doing the best we can.
Ryan coined the term ‘design plans’ when describing this concept to the team. In working with Atlassian tools to help members of the Department of Defense with effectiveness, he recognized an opportunity and built an innovative way to define a set of reusable components, workflows, data elements so we could collectively understand. Coming from a broad, engineering-dense set of experiences, Ryan used that experience to attempt to track down existing patterns built by others. Perhaps service companies see those solutions as competitive advantage, but thus far research returns less than thrilling results. In the first fleeting days of the implementation process we created at least three reusable solutions for our government partners to liberally plagiarize, a master tracking tool, information streams, and roll up reporting. Now, when we run into these types of needs, we can more rapidly deploy solutions and innovate only when necessary.
When generating new requests, the team has the ability to reference documentation that enables even a junior resource to implement these repeated patterns. If there is a need for variability or if the solution is a bad fit, we can enable conversation with clarity and understanding. Additionally, new members of the team can learn from the existing pattern library. Instead of building a rickety bridge, we can build resilient, tested solutions.
Ryan
So Ryan is a unique guy, aren’t most engineers? One tradition he has is dressing up (we’re very casual) on days we have VIPs on site and sitting at the owner’s desk. Here’s a recent picture to provide proof.
