Subscribe via RSS

The Dangers of Git ‘R Done

Filed Under Human Factors, Quality Controls

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.

RSS Icon

  Don't miss a drop! Subscribe now via RSS or email.


3 Responses to “The Dangers of Git ‘R Done”

  1. Jason on June 29th, 2007 8:25 am

    This is good stuff. I see this kind of compromise pop up everywhere. It would be interesting, however, to know the exact wording on that survey. The text “3 working features than 5 semi-working features” seems, to me, to introduce an immediate bias in the response. Something a bit more scientific, although probably still biased, would be:

    Would you rather have 3 features tested 3 times, or 5 features tested once.

  2. Max Pool on June 29th, 2007 9:31 am

    I do not know the exact wording but I do know that we walked away with the generalization that customers were more satisfied with quality over quantity. Your comment of 3 features tested 3 times, or 5 features tested once is a great segue into an example…

    A few times a single customer wanted two different systems built concurrently. One team did TDD, and the other team did all unit testing after feature complete. By the end of the two budgets which solution did the customer like the best?

    The TDD team only delivered 85% of initial features but was rock solid.

    The non-TDD team was 110% feature complete (as the customer kept adding new features) and had 0 tests built and was buggy. As a result, they had to run over budget to create tests and fix bugs.

    So which is better? It is all in the eye of the client I guess…

  3. Paul Nash on November 14th, 2007 10:45 am

    error on the side of quality … indeed!
    A very good principal.
    Seriously, I noticed a few spelling errors on these pages, e.g. complaint for compliant.

Max Pool - © 2024 - {codesqueeze}. Sycorr Banking Solutions