Errors are huge in development. As is error handling. Sadly not a lot is written about best practices in error handling. Most languages favor one way to handle errors and apply that to all cases. Developers tend to ignore errors or take the mechanism that is in hand. This article goes a little deeper into ways to handle errors and I share some thoughts on what error cases might be best handled by what methods. Continue reading Some Thoughts on Error Handling
Scrum is not about engineering practices – which is a good thing. Martin Fowler writes:
They adopt the Scrum practices, and maybe even the principles
After a while progress is slow because the code base is a mess
and connects Scrum failure to missing engineering practices. This completely misses the point. Scrum is not about engineering practices, it’s about management.
Engineering practices are a responsibility of the team. Scrum creates self organized teams. They organize themselves, they organize their quality. They organize their tools. They organize their engineering practices (TDD, pair programming). Why? Because they are responsible for delivering. No one else is.
Craftsmanship and level of done
Often quality and craftsmanship are organized by a level of done agreement in the team which describes what a team considers when code is done. This can include
- Documentation / JavaDoc
- Functional tests
- Unit tests
- Bug free
- Refactored, maintainable code
- Reviewed code
What about technical debt? Technical debt is not professional. Seeing an ice berg and keeping a crash course is not professional. With the right level of done there will be no technical debt.
Scrum helps with good engineering practices
Concerning Marting Fowlers comments Dean Wampler twitters:
His comments match my experience at client sites. Teams using Scrum w/out the XP prog. practices don’t work long-term.
Not very insightful it says: developers who do not use professional practices will fail. Of course they fail, but they fail independently of the process you use.
The main difference to classic project management is that developers have the freedom to define their level of done and the amount of work they do. Developers define what stories they work on in each sprint, management doesn’t set a (unrealistic) finishing date as often happens in classical software projects.
Is there too much quality? Doesn’t the product owner care if the team takes “too much” time for quality? The product owner is entitled to two things:
- Story estimates
- Shippable products
- Professional developers
The product owner is not entitled to speed. Scrum sets resources and time in the Iron Triangle and let’s developers decide about scope. Speed is scope / time and is an output variable of the team, not an input variable. If she thinks the velocity of the team is too low, talk to the ScrumMaster and remove impediments. But engineering practices should never be dropped. Other crafts will never drop theirs. Ask a doctor to drop sterilizing to gain speed. Ask a banker to drop double-entry bookkeeping. They won’t. Neither should developers drop theirs .
 This could mean developers need to be trained to be professionals. But a company needs to teach professionalism to developers independently of what process it uses. If you do not have skilled, professional developers you’re doomed and no process will help you.