The Dangers of Git ‘R Done

Jay Kimble recently wrote a post titled Git ‘R Done coding. I will agree that there is a needs to be a trade off between expediency and maintainability, but it saddens me to see that a lot of people are blindly supporting this mentality without researching the dangers.

Morts and younger programmers may not have the experience to walk the fine line between responsible software architecture and ‘quick hacks’. As a result, this is a very dangerous message to those developers with not enough maturity to make these decisions (but are forced out of necessity).

A number of driving factors exist why developers practice unhealthy expedient programming techniques:

• Trying to match fictitious budgets or timelines
• Attempting to pull higher profit margins off of fixed budget projects
• Fighting potential embarrassment of not finishing on-time
• Egotists attempting to over-deliver

Walking this line is tough for even veteran developers. I would argue that this is because it is an art form in mostly client communication and compromising. But I digress…let’s stay with the situation where a developer has to make a client assumption on expediency vs. maintainability. What are the top 3 questions you would ask yourself?

1. Does the client appreciate Expedience over Stability?

For example, assume we are talking about auto mechanics. Would you rather have your car fixed faster but run the risk of breaking down, or have your car fixed correctly but be in the shop longer? A small survey at where I work reveled that clients would rather have 3 working features than 5 semi-working features. This seems common sense, but many developers forced to make assumptions will choose to create more features than fix the ones they have already coded.

2. Will the solution significantly destabilize if I make a hack?

Can your application handle another hack? Has it been a fortress until now, or has it slowly turned into a card house? This is the judgment call of the developers. Unfortunately, it is often incorrectly left to the client to decide. This is where the developer needs to be honest and propose compromises.

For example, a client requests a feature that will not easily fit into your current architecture. If a hack will not destabilize anything, a hack might not hurt. If you have to refactor code just to fit the hack in, you might be in trouble. In either situation the solution is simple, lay the cards on the table and when in doubt ask the client Question 1..

3. Is the client willing to compromise on this feature?

Most clients are not married to the features that they request, instead they are passionate about the domain problems that the features solve. Proposing new features that accomplish the same task can satisfy both client and programmer.

Other compromises can be made:

• Reduced Price
• Delivery of feature in next version
• Trade some features for others

Still not sure of what to do? When in doubt, error on the side of quality and aim for perfection. Anything short of asking the above 3 questions and you are making dangerous assumptions.