The paper contains 2063 words and is expected to last 4 minutes
The world of programming is not just about code. Many organizations start with the assumption that all developers need to learn is a programming language. But for developers to be productive, organizations must also understand the nuances of code and how they relate to what is encoded.
Code is more than code; it codifies rules and integrates people’s understanding and interpretation of programming content. If developers can’t understand what they’re programming, they can’t work effectively.
That’s why developers are more than just program monkeys — their job is not limited to typing for a given, relatively vague marketing need. While this is common, the truth is that developers should never stop there — especially if they want to be an agile developer.
Misconceptions about Agile
Agile is an interesting word. A lot of people seem to “get” it. Companies, in particular, believe they are doing this. But a lot of people get it wrong. For the most part, agile turns into a strange cascade of development. It is not uncommon for a project to be divided into several phases and finally delivered to the customer all at once.
In waterfall development, or pseudo-agile development, the developer is not involved in the middle process, only responsible for the last process. But developers are not masons and should not be treated that way.
When Martin Fowler, Robert Martin, and 15 other software development leaders signed the Agile Software Development Manifesto, their focus was on revolutionizing the way software is developed to give developers more effectiveness and autonomy in their work.
This is partly because they recognise that developers are not robots who simply carry out other people’s plans. They are also architects, engineers and builders, often packaged into a unique role. They are your full-stack engineers, software developers, IT operations technicians, and hybrid developers with cross-cutting areas of knowledge and technology. They are technical professionals and generalists.
How can companies change this
If a developer feels like a programming monkey, solving that problem is an organization-level process and structure problem. If you are part of a small start-up, it may be easier to deal with this than in a large company with entrenched mindsets and established working relationships.
The purpose of agile development is to create speed and mobility for the enterprise through circular delivery. Contrary to popular belief, software is never a complete product. People make changes to software all the time — whether it’s because of a market need, a bug caused by unforeseen circumstances, or a change that is critical to the company’s growth. The only constant in software development is change itself, and it can’t be avoided.
To cope with these changes, development teams need to be small — small teams in the single or low double digits that can be fed on two pizzas. Jeff Bezos calls this the “double pizza principle.” There’s nothing wrong with having multiple teams on a large project, but it’s important to keep the numbers to a minimum so that people can communicate effectively.
Each team may be responsible for a function under a team lead or lead, but the team lead or lead must effectively communicate the strategic development plan to each member. This is critical because it allows developers to envision code and structure ahead of time and to come up with effective ways to automate processes and align their output with enterprise requirements.
Create code autonomously and responsibly
The code may be the final output created by the developer, but it is also influenced by marketing, management, the business team, and anyone else involved in the final output. When something goes wrong, you can’t just blame the code.
The most effective developers are also involved in other processes such as communication, story creation, final decision making, and sequencing of deliverables. This involvement is important because it allows developers to understand the domain in which they are coding. If developers do not have knowledge and practice in this area, or a solid foundation in this area, they will not be able to effectively translate the rules and requirements of the enterprise into ‘computer language’.
Programming is not just a programming language, but an integration of rules and expectations that computers can understand and reproduce in a way that humans can understand. If the code is corrupted by a developer’s misunderstanding of the source code, assuming their competence is not in question, it is a failure to accurately understand the enterprise’s requirements for digital material formats.
What can you do about someone else’s code?
Sometimes, a development team may inherit code from a previous team. The code might be fine. But more often than not, this code may not be applicable now because of legacy methods, outdated formats, and then popular but now inefficient engineering patterns.
This happens all the time, especially for those who have been in software development for many years. While this code is an outdated product, the organization and its teams are still responsible for it. Every software, hardware and infrastructure has a shelf life beyond five years to be tested and made fit for the new age. Just being functional doesn’t mean being productive — it can also be a major bottleneck to a team’s ability to develop agile.
Developers know this best, and when engaged in higher-level communication and decision-making, they can fully plan updates and create contingency plans to mitigate the risks posed by legacy systems. Adding new functionality directly to a legacy system is like removing the beams before checking the structural integrity of an old house. If you do, you never know when or if the house might collapse.
conclusion
Code is like digital real estate, and companies need to accept that developers are more than just programmers. When developers are seen as part of a cohesive, cross-functional team, their coding capabilities are effectively enhanced.
Putting developers at the end of a project is like building a house with a few sketches and a flat top. It is the developer’s job to select, build, beautify, and all the processes in between to turn the enterprise’s vision into reality. That’s why it’s critical to get developers involved early in the project lifecycle.
Leave a comment like follow
We share the dry goods of AI learning and development. Welcome to pay attention to the “core reading technology” of AI vertical we-media on the whole platform.
