Bottom-up

For years, working in a bottom-up manner has been seen as the ugly step-brother of the exemplary top-down approach. Going bottom-up was greedy, lacking direction, trying to achieve things now without thinking about the future (sounds like someone you know?). Instead the right way was orderly defining your goals, laying out a plan, refining the plan until you reached the state of simple steps.

Nowadays the bottom-up approach is rehabilitated. And this was a parallel development in different domains:

• GTD is a bottom-up-driven methodology (see the wired-article).
• Agile Processes value responding to change over following a plan

What caused this paradigm-shift?

One of the reasons is that the pure top-down-approach relies on two things:

• You have to be good at planning (what people usually aren't, see Why Your Plans Fail)
• The target has to stay constant (which it usually does not - requirements change by a few percent each month)
  

As one of the mantras of XP (Extreme Programming - an agile methodology for software development) goes: Embrace change.
Change happens. And it happens more frequently than you think and in another direction than you think. But change does not have to be a bad thing. Change can be an opportunity. And the "new" methodologies prepare you to grab those opportunities.

GTD gives you a "mind like water" to be ready for anything that comes up. You do not have to reorganize everything, you just create new projects and a few new "next actions" and weave them into the "stuff" you already had on your lists before the change. Your weekly review will help you to eliminate anything obsolete.

In Agile Software Development, you have working software that delivers as much business value as possible. You didn't allow technical debt into the project (constant refactoring). The continuing contact to your customers makes you aware of changes in their priorities as soon as possible. The technical base helps you to react as soon as possible, you don't have to go "all the way back" to the early waterfall phases. Instead your next iteration or scrum or whathaveyou will focus on the new features your client needs.

The theme is the same. Being well-organized in your smaller steps allows you to shift direction when needed. I think it was "Pragmatic Programmers" where I first read the comparison that developing software is a lot like driving a car: you don't determine an exact direction, set your wheel precisely and drive for miles with the steering wheel in this direction. Instead you point the wheel in an approximate direction, start driving and continue to adjust the direction very often in very small amounts. Obviously this involves frequently looking at the discrepancy between where you are going and where you should go.

But remember (teacher-mode on): this doesn't mean you can be unorganized and just label it "bottom-up"!

Make it part of the system

GTD is a lot about "getting things out of your head into a trusted system". Keith Ray and splogs discuss a property of some programming languages that helps you to do just that.

Their topic is const-correctness, a major issue in C++ (which happens to be the language I am mainly working with). Adding const to a variable or method just says: "This variable won't change" or "This method doesn't change the object, on which it is called".

As a colleague once correctly observed, adding const in most cases doesn't change the program that is being compiled. But what he failed to realize is, that you put some knowledge you have when you write the program into the source code. This allows you to forget about it. The interesting thing happens when you revisit the code (either to debug or to change it): with const in it you instantly know something important about the variable/method. Without const you have to try to either remember something or rebuild the knowledge. Not knowing something is const means you have to carry more stuff around with you.

As splogs said:

"When a software developer is debugging a program (as s/he often is), just knowing that one "thing" will not change after creation decreases the scope of required knowledge for that session by one."

So the source code is a trusted system (the compiler actually tells you, if something contradicts the const-ness) to put your knowledge into.

Designing programming languages and teaching good programming is a lot about reducing the amount of knowledge the programmer needs to achieve one task. Examples are

• reducing the scope of entities
  
• achieving high cohesiveness and low coupling
• striving for orthogonality
• grouping of code and corresponding data (the core of OO)

Getting const-ipated is one way for software-developers to get stuff out of their brains into a trusted system, so they can focus easier on the task-at-hand.

Additional tricks include leaving a breaking task as a reminder what you were doing at, when you have to stop working on something before finishing it. If you don't happen to have Unittest, you might introduce a syntax error, but this doesn't tell you what you were trying to achieve.

About

About "Getting Programming Done"

In this blog I will connect two fields that I am interested in and that are relevant to my work:

• Software development, especially from the agile and/or pragmatic point of view
• Personal productivity, especially David Allen's "Getting Things Done (GTD)"
  

In connecting what is happening in both fields, I try to

1. Compare them.
2. Look for mutual inspiration (both ways).
3. Develop a personal productivity approach for software developers.

About me
I am a senior software developer (C++, computer vision) turning into a project manager. I try to introduce agile methodologies into the company but we are not implementing a full-blown XP/Scrum or other approach.
I have recently started adapting GTD to coordinate my different work tasks (software development, management) as well as my private life.