This is something that is very difficult to convince the business heads. Deborah Hartmann discusses Ken Schwaber’s presentation – The Canary in the Coalmine. Ken has been able to highlight code quality as an executive decision, or as a corporate asset.
Worse yet, our pattern is not to tell anyone, right? So a classic thing we do now is: if you are in a release and the customer absolutely has to have it earlier and the quality has to be dropped… that is not a Product Owner decision, that is not a Customer decision, that is a drop in the value of a core asset of the company, and it has to go in the books. That is a CFO, COO, CEO type of decision.
Timeline and Deliverables
These situations are usually faced by the teams which cannot realise earlier the incompatibility between timeline and deliverables. That is why it is important to break into iterations and use some time to review both of them. Iterations have been very useful in doing short testable releases, but giving some time to check the track can be immensely useful.
As Ken suggests, one of the best things to do is apprise the heads about inevitable situations earlier. The possible solutions will be much better than anything that is done at the twelfth hour.
I have created my own solution points to avoid running into such problems and maintain code quality.
Identifying Dependencies
Another reason that I have seen is inability to identify dependencies between various modules, components, or subsystems while developing. If module B depends on module A then A has to be ready before A can be developed. However, this linear development is not practical. What is required is to decide the communication between A and B, decide what A and B expect from each other or design their interface. Unless this is done it more than just probable that more time will be spent in redoing or rewriting code – one of the biggest hurdles in productivity. Identifying dependencies and designing interfaces is something that can help parallel development without having to rewrite.
One of the causes why dependencies are not identified properly is because the requirements are not available to the developers. They are usually hidden, for a lot of reasons, because of which the developers cannot understand implications of use of their code in the business. If the requirements are transparent, the design and development can work better to target them.
Framework
Ken Schwaber talks about unmaintainable, cobbled up legacy code which usually composes the core functionality. Everything else depends on it. It is some kind of a sacred piece of code where only the pundits are allowed, and not ready for change. I agree with a lot of it, but I still believe in the library/toolkit/framework way of development.
What I mean by framework way of development is separating business code from the technical code. The technical code should be closed for modification but open for extension. Then it can be reused for multiple business functionalities. For example, a calendar can be used to calculate the salaries or vacations or plan home projects or set reminders. In all these cases, the functionality of calendar should be separated from its business uses. A well designed framework leads to development of maintainable code.
They can be sometimes packaged together for convenience, but internally they should still be separated. Separated to an extent that the business functionalities can be separately developed over it as a third-party library. To be able to allow all this, calendar has to expose extension points that other can extend for different types of use. This might lead to more time spent on developing the calendar, but it will reduce the time required to build the different business functionalities over it.
Stagger Requirements
Sometimes it is really beyond the physical capacity of delivering so much in so little time. The best way that I have realised is to stagger the requirements in phases. However, this requires more interaction with the customer and certain level of trust. I use the concept of core requirements proposed by RUP to stagger requirements because they help in identifying the dependencies.
I am sure there are many more suggestions, and that they have to customized for the team. However, in my opinion, the most that hurt are improper requirements gathering and no explicit design for interfaces.
