My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Every day, psychological barriers are erected around us, and depending on what task they are a stumbling block for, they can be helpful or a hindrance.

Ramit Sethi wrote a guest post on personal finance blog Get Rich Slowly about passive barriers that got me thinking about passive barriers in software development, or perhaps just any easily destroyed (or erected barrier) that prevents you from doing something useful (or stupid). One example he uses that comes up a lot in my own work references email:
I get emails like this all the time:

"Hey Ramit, what do you think of that article I sent last week? Any suggested changes?"

My reaction? "Ugh, what is he talking about? Oh yeah, that article on savings accounts ... I have to dig that up and reply to him. Where is that? I'll search for it later. Marks email as unread"

Note: You can yell at me for not just taking the 30 seconds to find his email right then, but that's exactly the point: By not including the article in this followup email, he triggered a passive barrier of me needing to think about what he was talking about, search for it, and then decide what to reply to. The lack of the attached article is the passive barrier, and our most common response to barriers is to do nothing.

(Bold emphasis is mine).

If I can't immediately answer an email, it gets put on hold until I have time to go through and do the research that I need to do to give a proper reply. Sometimes, that means your email never gets answered because eventually I look down at the receipt date and say to myself "I guess it'd be stupid to respond now." But I digress.

In everyday software development, there are a number of barriers that can help us:
  • Minimizing or closing the browser. When a compilation is expected to take up to a minute, or a test suite will run for too long, or a query takes forever, there's not much work that can be done, so I might fire up the feed reader, email, or twitter to pass the time away. The problem here is that you'll often spend far longer on your excursion than it takes for your process to complete. If you waste just 5 minutes each time, you've accomplished nothing - you're just skimming and certainly not getting anything out of it, and you could have been back working on what you were trying to accomplish. In these situations, I have my email, feed reader, and twitter minimized, and that significantly reduces the urge to open them up and start a side quest.

    If you wanted to get more to the active side of barriers, you might just add the line
    to your hosts file. That turns a passive barrier to time waste into a downright pain.

  • Having a test suite with continuous integration and code analysis tools running. At various points in a day you might be tempted to check in code that breaks the build or introduces a bug. This is especially true at the end of the day. However, if you have a test suite that runs on every commit, you're much more likely to run it to avoid the embarrassment of checking in bad code. If you've got static analysis tools that also report on potentially poor code, you're less likely to write it.

  • Annoyance Driven Development. This isn't one that I know how to turn on or off, but I think it would be a great feature to have in IDEs or text editors: it gets slow when your methods or classes or files get too big. This would be a great preventative tool, if it exists. I guess it falls back to using test suites and code analysis to provide instant feedback that annoys you into doing the right thing.

  • Working with others, or having others review your code. Most of us pay more attention to quality when we know others will be looking at the code we write. Imagine how much more of your code you'd be proud to show off if you just knew that someone would be looking at it later.

    Facepalm, when words fail to describe the dismay.
Just as well, there are also barriers that hinder us:
  • Interruptions. This one is obvious, but so pervasive it should be mentioned. IM, telephone calls, email, coworkers stopping by to chat or ask questions - they all prevent us from working from time to time. The easy answer is to close these things, and that's what I do. They all represent passive barriers to getting work done, and you can easily turn that around to be a passive barrier against wasting time (see above). Pair programming is an effective technique that erects its own barrier to these time wasters.

    If you're really looking for something to help you focus, I'd have a look at The Pomodoro Technique, which divides your work into tomato time units of 25 minutes each, which really helps you focus on work. It's agile for time management. (The Pomodoro Technique PDF book is available for free.)

  • Rotting Design: Rigidity, Fragility, Immobility, and Viscosity. Bob Martin discusses these in his (PDF) article on Design Principles and Design Patterns. Quoting him for the descriptions, I'll leave it to you to read for the full story:
    Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules. What begins as a simple two day change to one module grows into a multi- week marathon of change in module after module as the engineers chase the thread of the change through the application.
    Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way.
    Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that it depends upon. After much work, the engineers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate. And so the software is simply rewritten instead of reused.
    Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.
    The point is that poor software design makes an effective barrier to progress. There are only two ways I know to tear down this wall: avoid the rot, and make a conscious decision to fix it when you know there's a problem. There are plenty of ways to avoid the rot, but books are devoted to them, so I'll leave it alone except to say a lot of the agile literature will point you in the right direction.

  • Unit Tests. I struggled with the idea of putting this on here or not. If you're an expert, you already know this. If you're a novice or lazy, you'll use it as an excuse to avoid unit testing. The point remains: unit testing can be a barrier to producing software, if you are exploring new spaces and having trouble determining test cases for it. I'll let the Godfather of TDD, Kent Beck, explain:
    ... I still didn't have any software. As with any speculative idea, the chances that this one will actually work out are slim, but without having anything running, the chances are zero. In six or eight hours of solid programming time, I can still make significant progress. If I'd just written some stuff and verified it by hand, I would probably have the final answer to whether my idea is actually worth money by now. Instead, all I have is a complicated test that doesn't work, a pile of frustration, eight fewer hours in my life, and the motivation to write another essay.
These are just a few examples, so I'm interested in hearing from you. What barriers have you noticed that positively affect your programming? Negatively?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and C++ (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner