I attended the Scandinavian Agile Conference 2011 and listened to Jason Gorman’s presentation on The Imperative Software Craftsmanship. Gorman’s talk, however brief, gave me the nudge needed to start structuring my views on how I see my occupation as a software developer.
“The only way to learn how to code is to actually go out and code.”
“The only way to learn how to code is to actually go out and code.” I’ve heard this statement many times from the so-called experienced programmers. In my experience this perception takes time to mature. Typically the more mature programmers also start to emphasize quality aspects of their work.
“Only after this ten year ‘internship’ can one start dreaming of someday mastering the art.”
Coding is in many respects comparable to the traditional crafts: the basic theory and techniques can be learned from books, but only through actual practicing can one eventually become a true master. Experience can’t be rushed. As an example in the craft of glassblowing there seems to be a consensus that it takes at least 10-years of practicing to reach a stage of maturity. Only after this ten year “internship” can one start dreaming of someday mastering the art. After almost 20 years of programming Gorman calls himself a journeyman programmer. He still gets inspired from the displays of excellence by masters such as Bob Martin and Ward Cunningham.
A software developer improves her programming skills in software projects. An agile software project has a goal, which a team is formed to accomplish. The goal is met through series of incremental prototype versions that are built iteratively to the best of the team’s know-how. The project owner sees the iteration outputs in demo sessions and uses the wisdom gained from them as the basis for steering the project.
“In modern organizations results are needed yesterday”
For projects that span over a year the team’s ability to react to change is of great importance for the overall result. In modern organizations results are needed yesterday, pressuring the team to work too fast for their abilities. Gorman spoke of anaerobic software development: “When teams write code at an unsustainable pace, code smells build up faster, making progress increasingly difficult and painful.” Without adequate skills or discipline, a speed too high will rapidly decrease the team’s productivity. This means that the cost of change will increase. Soon the benefits derived from the change won’t cover the cost of the change anymore.
“If you don’t understand your own code, how can you expect someone else to understand it?”
Gorman specified five cost-increasing factors in software development:
- Poor readability of the code
- Complexity of the code
- Code duplication
- Coupling of code and the resulting ripple effects
- Inadequate regression testing of code
According to Gorman our ability to understand a piece of code affects crucially our ability to change it. Even code you have written yourself will be difficult to understand over time if its clarity and readability are neglected. If you don’t understand your own code, how can you expect someone else to understand it?
Complex algorithms and code structures increase the possibility of something going wrong. If something goes wrong, it needs to be fixed. That costs money. A large amount of duplicate code means that a fix has to be implemented in many parts of the system. The resulting code must be maintained. When a component is broken, a dependent component might also brake causing a butterfly effect. Without adequate regression tests the developer has no way of knowing things have gone awry. The cost of this will be unbearable for any organization.
It requires a right kind of learning environment to evolve as a programmer. Junior developer needs the hands-on-example of a senior developer. He also needs to be continuously confronted by demanding challenges that put her learning to the test. There has to be room for errors.
“An imitation eventually develops into a habit”
Furthermore, as Jason Gorman’s presentation outlined: the “pupil” has to want to learn. Gorman’s way of promoting high quality programming is based on continuous training. The team should agree on a set of practices that every team member commits to. The more experienced developers help the inexperienced ones and little by little the practice that started of as an imitation eventually develops into a habit. It is essential that even though experience levels might vary, every member of the group is considered equal. Trust is the cornerstone of building a learning-friendly and truly fertile development environment.
“So how can one differentiate an experienced programmer?”
So how can one differentiate an experienced programmer? In assessing the experience level of a developer Gorman advises people to follow the person in action: if you want to know how good a juggler is in juggling ask her to juggle for you. While assessing the skills of a junior software developer the more experienced one literally logs all the deviations from the agreed practices. The stumbling logged during the assessment is not to be held against the assesse but to be given as a foundation for improvement.
“Repetition is the key and there are no shortcuts”
Finally Jason Gorman reminded the listeners of an old saying about a tourist in New York asking renowned violinist Jascha Heifetz how to get to Carnegie Hall. Practice, practice, practice was the answer. Even though the saying is meant as a joke I think it contains the essence in becoming a craftsman: repetition is the key and there are no shortcuts.
I believe I’m fortunate to work in an organization where it’s possible to evolve as a professional software craftsman.
How do you see your occupation as a software professional?