We have been doing Agile for over 10 years now and we have been focusing on people, interactions, team building, the ecosystem. As a result, we are now working in a software environment where “processes are more important than technical practices”. This is how Sandro Mancusso started his keynote at ITAKE Unconference 2013, a talk that was very appreciated by the audience. You can watch the video or continue reading its summary.
Agile in Software Development is as much about programmers and technical practices as it is about processes. The real deliverable is the working software built with well-crafted code. “Software crafters care about delivering value with well-crafted code”.Even more, for them Software Craft means putting responsability, professionalism, pragmatism and pride back into software development.
Well-crafted code
Most of us consider this impossible to have. Why? Because we are always developing software under pressure. But are we sure we can’t overcome this hurdle? We can, if we write well-crafted code. Technical debt and bad code will always increase the time spent per feature. This increase is less noticeable in Agile because stories get sliced into smaller ones.
Early feedback
Agile talks about getting constant feedback. The problem is that we are considering only the customer feedback. But what if it comes late? What if it comes after we have wasted time implementing the wrong stuff? How can we find out early that we are building the right thing in the right way? We need faster feedback. How to get it? XP technical practices are known to help developers with that. You can get early feedback:
- from the client regarding the acceptance tests written before starting implementation on a feature
- from unit tests that the code is doing what is supposed to do
- from the acceptance tests that you have finished implementing the feature
- from all automated tests that no regression bugs have been entered
- from code review that the design is good
- from pair programming that the collaboration in the team is good
- from continuous integration that the deployment scripts are working
Professional programmers
Agile talks a lot about Scrum Masters and Product Owners. But what about the programmers?
They need to be happy to be productive. When are they happy? By learning new techniques and practicing them. But how to learn new techniques, if they are always working under pressure?
There’s an underneath assumption that they need separate time and planning for learning and improving their technical skills. This assumption is wrong. Step by step, programmers can learn new technical skills by practicing while implementing new features from the product backlog. The client or the manager does not care about how the code is written, they care about working software delivered without bugs. Customers or managers are not forbidding the use of unit tests, TDD, automated tests or design patterns.
The programmer is the owner of the code and the owner of his career. She is in charge with creating well-crafted code. She has to choose to use the technical practices that help her write good quality code. Continuous improving and learning leads her to professionalism.
Software Craft
…“is the movement that promotes the idea of adding value to software development through practices. It’s about leading by example and showing how we can be better. It’s about continuously delivering value and avoid writing bad code.”
Are you a software crafter? Do you want to be? Watch Sandro Mancuso’s video from last year and don’t miss him this year also at I T.A.K.E. Unconference!
The title is self explanatory, and technical debt can be a serious point of consideration for IT development companies if they decide to survive in the market for longer durations and still churn out profits through successfully completed projects. Feedback-oriented-development can be a great thing for IT companies but what if the product definition keeps on changing continuously with changing market conditions? How can technical debt be calculated if a project is successfully completed and released at one stage, and subsequently it starts losing its importance and worth simply because over time the end user requirements change? A highly successful project may incur technical debt if it phases out over the years owing to the emergence of new platforms and IDEs. How should technical debt be ideally interpreted? With respect to the development carried out in the project or in accordance to the sustainability of the project over the years?