And to clean up the list of disorders within a timely fashion. Of course, you and your team have to decide on what you consider technical debt within the project. But make sure you all agree on what the quality standard is. Otherwise maintaining a zero tolerance policy will be ineffective, and may cause frustration. Implementing this strategy is something you can start doing today. If you start pointing out and act to the so-called technical debt, you will soon start a movement within your team.
You will create awareness and team members will follow your example. Social control on the subject will grow, which encourages to stick to the set quality standards. How the broken windows theory relates to software development This theory applies to quality in software development as well. How it works The mechanic about this effect is that you unconsciously and gradually lower the norm of quality of your software. Wilson and George L. If the windows are not repaired, the tendency is for vandals to break a few more windows.
On the other hand, if there are broken windows the signal is: criminals welcome! Targeting minor disorder could help to reduce serious crime. People see the nocive habits as the norm. If nobody cares about litter, broken windows, spray-paint graffiti on walls, the neighborhood will start a negative feedback. Bad habits could get the place messy, opening the doors to crime.
They set bad habits in toddlers, completing the feedback loop. In software development, the disorder or entropy as an analogy of the second law of thermodynamics is Software Entropy. The disorder affects source code, databases, and configurations. Lehman, M. There are two forces fighting. First one tries to focus on the immediate problem, increasing the technical debt.
The second one is telling: do refactoring, standardize and document, find root causes of the issues. If first force wins there is no work against entropy making debt.
Technical debt is the cost of additional rework product of choosing easy tricks or hacks instead of a better approach. The latter would take a longer time to implement. Debt accumulates over the time. As any debt is bad when skyrocket.
Hacking bugs in the code is a good thing if there is a deadline. Everything is supposed to be laid out for her, and if there are any challenges, she can ask the local sheriff — ehem the development lead for some help. She is spoon-fed, and this is how they want her to be.
In the end an army of Quality Assurance professionals are going to test the code and make sure that it does what it is supposed to do. However, spaghetti spaghetti, copy-pasta, mangiare… Good code this does not make.
Well, if you can't recruit the best and brightest and can't Moneyball your way to them, what other options you as a software development manager have? It was told that in the early days of Facebook, the slogan was "move fast and break things. Many companies have realized the need for proper software architecture. This architecture is, for example, a house with proper security measures that make it hard to vandalize.
The rise of Microservices in recent years has allowed teams to focus on writing their best code possible by making the task more manageable. A smaller service means that developers only focus on the part of the code they can understand and better manage.
Bad code is mostly the effect of working in a huge code base that you can't understand akin to living in a city that is run down by crime. An old Egyptian saying goes "Would the guest not dance if the host is playing the tambourine?
Yet architecture is not a panacea. We all know of architectures that are not respected or are so rigid that they don't keep up with the current business requirements. At the same time, a single sheriff can't monitor a large enough software team. What can be done? The " eXtreme Programming " movement has a straightforward premise: take good software development practices to the extreme.
This is where pair programming has been mostly successful. Put two developers together on tasks and continuously rotate them.
XP is about method and philosophy and jazz, but mostly it is about test-first development, code quality, and pair programming. If you never did pair programming it can be intimidating at first or you might fail to see the value.
One programmer at the prospect of pairing was mostly concerned with his Spotify subscription "Should I cancel it since I need to talk to my peer. It's such a waste of time".
Two mice. Two keyboards. Two screens mirroring the same thing. And four sets of hands. The pair would swing between one writing the test case and the other coding the functionality. Between discussing the design and implementing it. Between telling a joke and laughing at it.
A short function. Straight to the point because the test was written beforehand, and it forced her to have a small manageable function.
At the same time, the test-driven nature means that you are making code that will document itself with tests. Code that will not regress. Code that is clean and pure. A panacea of having the best and greatest. A race to the top, instead of a race to the bottom. The two heads are reviewing the code. So you don't need a code reviewer. You no longer need a sheriff. The top coder on the team — selected by the team — will end up with a leadership role.
But this is a servant leader. Making sure the team excels. There's remote pairing with tools like Teams, Zoom, and others. Developers, Developers, Developers, Developers, Developers…. We come to close the loop with one word: Developers. Who doesn't remember the hilarious videos of Steve Ballmer shouting that he needs Developers to use Microsoft software? The same Steve Ballmer who halved the value of Microsoft. Yet he is right in a way, what is needed is developers. Good developers. Great Developers.
The problem with all these management schemes is to manage an army of mediocrity. If your army is excellent and strives for excellence, they will be self-organizing. They won't need huge layers of management. The managers' job would be just "Get out of the way and let the workers do their best. And indeed, this is what plagues a lot of Enterprises today. You might retort that it will cost you more. Yet all software costs money. The question is, do you want to pay the full price now, or do you want to get stingy, penny pinche, and in the end pay more when it comes to fix the bugs and restore order in the neighborhood.
XP has a moment of glory recently, mainly because it works.
0コメント