Deliverables On-Time vis-a-vis Technical Debt Risk

When we are working under tough deadlines and there is mounted lot of pressure on software engineers to crank out features by features in a short time to meet business needs, there are high possibilities that software system end up getting high technical debt.

Is it that delivery managers are not aware of above fact? Most of the times they are. However, they compromise on software quality against the need to take the product to the market. So far so good. However, they should make it a point to clear out some of those debt with a release just meant for that. These kind of releases are sometimes also called as “code refactoring” release.

What are some of the basic quality characteristics that can be avoided easily even in the case of working under tough deadlines?

1. Duplication (block level): I see this as a silent killer considering maintainability aspect of the software code. Generally speaking, when one is targeting to release with tight deadlines, this sneak in very smartly without anyone’s notice as it very easy to duplicate (copy & paste). And, best thing is this achieves what you want and does not hurt at all. However, future changes to existing software entities (classes/methods) may start proving costly in terms of greater time to change and test. Thus, you may want to avoid the duplication (copy & paste)n as much as possible.
2. Code Complexity: Higher code complexity may act as an indicator for suspect of lack of cohesion, and hence lower re-usability of code. Thus, this does tend to hit the maintainability aspect of code as well. It would also hit the usability (readability) of code in adverse manner. Future changes to this code would start proving costly as it may require greater time to analyze, change and test. As a thumb rule, you may want to avoid lot of decision points (if/else, for/while, switch/case etc)  in the same method while writing the code.