Search | Blog | Contact

Discipline often directed at the symptom, not the cause 15

Posted by Brett Schuchert Sat, 01 Mar 2008 22:18:00 GMT

Have you ever heard something like?
If the developer just had a little discipline and did it the right way, we would not have this problem.

That’s often a sign that the way something is getting done is hard to do, not supported well or just plain works against against you.

Here’s an example I recently came across…

In a particular organization, part of their build system produces “project” information to allow for development on multiple platforms and with different C++ compilers. That’s excellent, it sounds like a great tool. For a developer to get started, he/she:
  • Checks out the source tree
  • Runs the script
  • Starts working

So far, everything is great and this part of their build system is essential to their environment – and good in general.

Here’s the next part…

To add a file to the system you have to:
  • Create the file
  • Update project information
  • Rerun the script to regenerate project information.

When I asked how long it takes to add a class, I was told about 5 minutes. So if I want to add a header file and source file, it takes 5 minutes. That’s a big problem. Why?

After this discussion, I heard one of the senior people lamenting that a developer had put another class in an existing file rather than creating a second file. He said something like “If the developer just had discipline, he’d to the right thing.” Those darn developers.

It takes 5 minutes to add a few files to a build. That does not include build time. That’s just the time to configure the build information.

Does 5 minutes seem like very much time?

Here are a few more thins I noticed(before I knew about the build system):
  • Some header files defined multiple classes
  • Some source files had the methods for those multiple classes
  • Some of the header files had names that did not match any of the classes defined in that header file

So is this a problem?

Here’s an important rule from Jerry Weinberg:
Nothing + Nothing + Nothing eventually equals something

5 minutes may not seem like a lot of time, and if it were isolated, then it’s probably not a problem. On the other hand, when you multiply it by a team and time, you end up with big problems.

Imagine, you need to use class X. Its header file is actually named Q.h and by the way, classes T U and L are defined in that file – none of which you want to know about.

So your class now has phantom dependencies on T, U and L. Also, how did you find the right header file? A quick search (time wasted). Someone changed U, so you end up having to recompile even though you don’t care about nor use (wasted time). I’m sure you can come up with a few things on your own.

So what do you do about it?

OK, first, do not throw the baby out with the bathwater. The original tool solved an important problem. But the first rule of problem solving, again from Jerry Weinberg:
Every solution introduces problems
The problems include (but are not limited to):
  • Time wasting adding files
  • It requires discipline to add new files, so it doesn’t always happen
  • A name is wrong, but it’s a pain to update the build configuration, so it doesn’t happen – not all the time, just every so often

Little by little, things get a bit more chaotic.

So now that we’ve observed a problem – some waste, we need to find a way to remove the need to update the build information and regenerate to even work.

I don’t know what’s going to happen with this group. They are hoping to perform some refactorings. Their system has quite a bit of coupling. One thing we can do to reduce coupling is:
  • Introduce interfaces
  • Inversion of Control
  • Identify seams and use some of Feather’s stuff to introduce them
  • Etc., the usual stuff to introduce seams and break dependencies.

But many of the refactorings they’ll want to use will involve creating new classes. Since that takes a little bit longer, it will slow everything down – or seem so daunting, it might not happen at all.

Here’s a personal example. A few years ago, I built the security system for one applications and then a suite of applications with single sign on. When I initially introduced the security system, many people wrote tests that would forget to log out, causing problems in both the real system and the simulator.

I kept grumbling. I though, “if people would just do it right, there wouldn’t be a problem.” If they just had a little discipline.

Independent of whose fault it was, it ended up being my problem – and, quite frankly, it was my fault as well. The solution was actually pretty easy:
  • Create an abstract test base
  • Change tests to use it
  • In the setup, the base logged in
  • In the teardown, the base logged out
You might think, “Duh!” and in retrospect, so did I. But that few minutes of effort:
  • Reduced code duplication
  • Increased the stability of the tests
  • Made it hard for people to mess up (so long as they used the correct test base – and I updated all of the tests that needed it, so going forward, people had correct examples upon which to base their work).

Ultimately, this removed a lot of my wasted time

Detecting waste is the first thing. Until you know it is a problem, you cannot do anything about it.

So, the next time you think something like:
  • If that person was only following “the rules”
  • If he/she just had a little more discipline
  • Stupid user, they should not have done that

Ask yourself if it’s possible that those statements are directed at the symptom, not the problem.

Comments

Leave a response

  1. Avatar
    Gerald Weinberg about 19 hours later:

    Beautifully described, Brett. Carrying the analysis of the example one step further, who is it wants the “project information”? Clearly, the developers don’t want it or they wouldn’t play tricks that nullify its usefulness. That’s a fundamental error in the design of this build system: asking people to bother entering information for which they have no use, from which they get no feedback.

    Perhaps the system would work better if the people who wanted or needed the project information were responsible for entering it (call them W). The programmer enters his/her work, the system notifies W that a new file has been created, then W enters the project information.

    Now the responsibility is in the hands of someone who (supposedly) cares about the quality of the information, and Ford’s Fundamental Feedback Forumula is satisfied. People are downstream from their own garbage, so the garbage will ultimately disappear.

  2. Avatar
    Tim 1 day later:

    I find that 45 seconds is the threshold. If something takes 45 seconds or more, then they are hesitant to do it and loath to do it often. Under 45 seconds one can absorb fairly easily.

    As a result, we find that the development environment needs to be mind-numbingly fast. Just my observation, I’m interested in seeing how other people clock their “hesitation threshold.”

  3. Avatar
    JJ 1 day later:

    The quote you stated at the start of the entry is quite unfair for the developers. It is not all their fault and I bet all products are products of their best work.

  4. Avatar
    Brett Schuchert 1 day later:

    I’m a bit on the fence regarding the first quote. I’ve muttered it myself so I’m biased. In addition, I’ve observed that left to our own devices, it’s easy to rationalize not doing something that ought to be done (rename that class, fix that method, run all the unit tests, update before checking in, etc.)

    On the other hand, it’s probably a good idea to assume people are doing the best they can and are doing so with good intentions (until proven otherwise).

    That being said, how many developers allow their bosses to dictate how they do their work? For example, “we don’t have time to do it right, just throw something together and we’ll fix it in test.”

    I understand that there’s a lot of precedence and politics surrounding that idea. Even so, that’s like when your parents asked you “If your friends jumped off a cliff, would you do so as well?” At some point, we do need to take responsibility for how we choose to approach our work. Part of what we should do in that regard is to challenge anything that is getting in the way of doing the best we can.

    And really, we cannot get rid of all discipline, right? Would we tolerate a person who:
    • Checked in code that does not compile?
    • Reformatted entire files to fit a personal rather than a project standard, thereby ruining file history and forcing extra merging?
    • Wrote stuff in a different language just because s/he could?
    • Wrote a custom XML parser because s/he didn’t like the one already in use?
    • ...

    There is some minimum standard of work and to accomplish that minimum standard will require some kind of discipline. However there’s a difference between necessary and incidental discipline. And what is necessary today becomes incidental tomorrow. It’s the constant questioning that’s really important.

    In the original example, having to enter a name into the build system is currently necessary in the as-built system, but it’s really incidental. It’s not to enforce some standard, that’s just the way the current system was built. However, it could appear as a necessary requirement – thus the original comment from Jerry Weinberg.

    So I think in the context in which the quote was used, I agree that it is unfair. But I would not agree that that particular quote is always unfair without considering the context. If I found a developer who refused to make sure his/her work compiled before checking in, and I could not break them of the habit, I’d fire them. In this case I would not penalize the rest of the team by slowing down the RCS just to make sure one person would play nice. So I see that as necessary discipline.

  5. Avatar
    Jon Scolamiero 1 day later:

    Brett,

    Great article! I’ve seen one too many developers nailed for being “inefficient” with the problem being tied to the various tools and practices they were required to use.

    -Jon

  6. Avatar
    http://www.blacktowhiteiphone4.com over 3 years later:

    Latest iphone 4 white Conversion Kit with white color is now available, Let’s try!

  7. Avatar
    Criminal Records over 3 years later:

    Since that takes a little bit longer, it will slow everything down – or seem so daunting, it might not happen at all.

  8. Avatar
    Matteo over 3 years later:

    Thanks for sharing this to us.

  9. Avatar
    Backup iPhone SMS over 3 years later:

    Keep your Contacts and SMS safe! Actually, the contacts and SMS have more values than a cell phone’s own value. You can pay money to buy a new iPhone, but cannot buy your lost contacts and SMS back. So it’s important for you to backup your contacts and SMS in iPhone. And we recommend you backup contacts and SMS regularly. Our backup software can help you take a snapshot for your contacts and SMS. Your important personal information will be never lost.

  10. Avatar
    iPhone SMS to Mac Backup over 3 years later:

    Would you like to banckup iphone SMS to mac, macBook, macbookPro as .txt files? Now a software iphone SMS to Mac Backup can help you to realize it.

  11. Avatar
    okey oyunu oyna over 3 years later:

    very informative paragraph …

    internette görüntülü olarak okey oyunu oyna, gerçek kisilerle tanis, turnuva heyecanini yasa.

  12. Avatar
    coach purses over 3 years later:

    Mr Coates coach purses is the longest U.S. market popular with one of the most successful leather brand. Mr Coates coach purses store represents the most admirable American fashion innovative style and traditional skills . Mr Coates coach bags have durable quality and exquisite technology, Conspicuous Coach Heels in the female consumers have good reputation. Welcome to our shop Elegant Coach Purses

  13. Avatar
    bagsupplyer over 4 years later:

    New brand Men LV Jackets from China for wholesale on line store

  14. Avatar
    Adidas Jeremy Scott over 4 years later:

    on a new collection of footwear for the spring Wing Shoes

  15. Avatar
    tn pas che over 4 years later:

    to code test first in the situation where you are basically researching the framework. However, with any framework, you are simply leveraging it to provide services for your apoooo

Comments