In the world of programming, there’s more to it than just code. Many businesses start off thinking that developers just need to learn the language and that’s it. However, to have an effective developer, they also have to understand the nuances of code and its relationship to the world it is encoding.
Because code is more than just code. It’s the codification of rules, of one’s understanding and interpretation of the world. Developers cannot effectively write something they don’t understand.
That is also why developers are more than just code monkeys — tapping away at their keyboards based on a set of given and potentially fuzzy requirements and dictations from marketing. It happens a lot but in reality, it shouldn’t — especially if you want to truly go agile with your processes.
The misinterpretations of agile
Agile is a funny word. Everyone seems to ‘know’ what it is. Workplaces are convinced that they’re doing it. Many have it all wrong and most of the time it’s simply a weird version of waterfall, all chopped up and delivered in chunks. It happens a lot.
The issue with waterfall, or pretend agile, is that developers are often excluded from the process and tacked on at the very end. But developers are more than just the brick layer and shouldn’t be viewed or treated as such.
When Martin Fowler, Robert C. Martin and fifteen other software development industry leaders put their names against the Agile Software Manifesto, their primary focus was to revolutionize the way software was built and give developers more utility and ownership in their work.
This came about in part because they recognized that developers are not robots who are merely executing the plans created by others. They are also the architects, the engineers and the builders wrapped up, often into one singular role. They are your full stack, your dev ops, your hybrid developers who specializes and have knowledge across different domains. They are specialists but also are also generalists.
What can we do as a business to change this
If your developers feel like they’re code monkeys, then it’s an organizational process and structural issue. If you’re part of a small startup, challenging this setup might be easier than in a larger and established company due to entrenched models of thinking and established workplace relationships.
The purpose of agile is to create speed and mobility for the business through continuous delivery of the software. Contrary to popular belief, software will never be a complete product. There will always be an element of change to it — whether it be in response to market demands, bugs arising from unforeseen situations and scenarios or pivots in a company’s direction. The only constant in software development itself is change, which is inevitable.
In order to respond to these changes, the team is required to be small — a single or low double digit, fed with two pizzas kind of small team. Jeff Bezos calls it the 2-pizza rule. There is no rule against having multiple teams to a big project but the point is to keep the numbers down to a minimum for effective communication between members.
Each team can be working on a single and isolated feature and coordinated through an effective team leader or manager that is able to efficiently and effectively relay strategic game plans to their team members. This is vital as it allows developers to plan ahead in their code and structures, figure out ways to effectively automate processes in order to align their output with the needs of the business.
Taking ownership and responsibility over the code created
Code may be the final output created by developers but it is also influenced by the input placed by marketing, management, commercial teams and anyone else that made a decision that contributed to the final output. When something goes wrong, the code itself shouldn’t be the sole place to lay blame.
The most effective developers are those who are included in the conversations, the user story creation, the sprints decisions and sequencing of feature deliveries. This inclusion is important because it allows developers to understand the domain in which they are coding. If a developer doesn’t understand or have a solid foundation on the business’ domain of knowledge and operations, they cannot effectively translate business rules and requirements into ‘computer speak’.
Programming is more than just a language. It’s the codification of rules and expectations in a form that computers can understand and re-render in a way that makes sense for humans. If the code is faulty due to misunderstanding by the source that created it, and if we assume that the developer has a certain level of competency, then it is due to a misstep in understanding exactly what the business wants on a digitally material format.
What to do about other people’s code?
Sometimes teams inherit code from previous teams before them. Sometimes the code can be good. Often times, it is bad due to legacy methods, outdated formats and engineering patterns that were popular back in the day but proven to be inefficient for your current situation.
It happens a lot, especially for those who have been in the industry for a certain number of years. Despite the code belonging to a different era, the business and its teams are still responsible for it too. Every software, hardware and infrastructure architectures have a shelf life. Anything older than 5 years should be reviewed and planned for migration out into the new world. Just because its working doesn’t mean it’s efficient — which can also become the major bottleneck towards your team’s ability to work in an agile manner.
In this area, developers know best and when they are included in conversations and decision making at a higher level, they can adequately plan migrations and create contingency plans to reduce risks caused by legacy systems. Telling them to add a new feature to a legacy system is like knocking out beams inside an old house that hasn’t been checked for structural integrity. When you do that, you never know when or if the room is going to cave in.
Final words
Trust your developers when they make suggestions that may impact your strategic stepping stones. Code is digital real estate and businesses need to accept that developers are more than just code monkeys. When developers are treated like someone who is part of a cohesive and cross functioning team, their ability to code effectively increases.
Tacking them on at the end of the process is like building a house with only a Pinterest board and maybe some drawings of what your house should look like. Developers are the ones that are doing the plumping, the building, the landscaping and everything else in between to turn your business desires into a reality. That’s why it’s important that you also include them as early as possible when in the project development cycle.
It’s better for a developer to understand the big picture of where you want to go and what you’re trying to achieve with your business. They are, after all, there to support the materialization of your business’ desires and strategic stepping stones as much as everyone else in the company.
