What Fraggle Rock Can Teach You About The Art Of Letting Go

Disclaimer – Before I really start brain dumping, let me be honest – this post might turn out to be hypocritical. It would be nice to think that with profound experience I am wiser and can understand how the moving nature of software works; however, I also realize that I am getting older which results in the growing problem of stubbornness and a general distaste for change. Alright, now let’s talk about Fraggles and software…

The need for clients to change direction on projects is a necessary evil to our profession. Without being able to iteratively see and touch the solutions we are building, they do not have the insight to make the correct decisions on the direction the project needs to take. However, it is these corrections that set software development back, that is, the constant rework that occurs when assumptions and constants change.

Thus far, the only constant I can assume is the constant of change, and how you deal with ongoing project changes speaks volumes of how far along you are in understanding this constant. If my warped mind was to come up with some evolutionary chart of attitude towards project change it would be something like this:

1. You Think You Know Better

The first phase of any fresh young developer is going to be the one of ignorance. Just because you can wrap your mind around a particular domain or problem, you will instinctively feel that you know more about the solution space than everyone around you.

Of course, this is a general lack of humility and humbleness. The people you are working under are probably smart people, and even though they may not know what they want or are generally bad at articulating thoughts does not imply they don’t understand their domain.

2. You Assume The Client Knows Better

In time, you will probably get your ass chewed out for overstepping your boundaries. This is when a little humility sets in and you attempt to open your ears with the assumption that the client knows better.

Now I know that 2 sentences ago I said that you work with smart people…well…this may not be the case. At this point, at least we are listening to the clients problems to gain a deeper understanding of the domain and its problems.

3. You Know You Know Better

At this point of your career, you understand the problem domain pretty well. You understand the ins-and-outs of the business and can make real contributions. The problem during this phase is that you get extremely pissed off when your solution starts to become the result of community solutions (caused by stakeholders need to feel important)

When projects take sharp left, right, and 180 degree turns, you somehow feel that it is your responsibility to either contribute a large amount of hours fixing the solution or argue your why out of the change. Very few developers ever leave this stage due to the high level pride in ones work.

4. You Know Clients Pay The Bills

This is the stage where you quit looking at the granular level of code, and start looking at the business. You quickly realize that you had your head in the sand for some time now (or most likely in a dark basement office with a nice coffee maker).

Now you are much more concerned about the business aspects of decisions. Sales and feature bullet points become much more alluring as previous priorities such as software integrity slowly melt away. It truly is humbling to realize one’s own hypocrisies.

5. You No Longer Care (And Just Keep Building)

Finally in the end, you realize it is a big Catch-22 and you concentrate all your efforts on just getting things done. Both sales and software integrity become equally important but not as much as productivity. You realize you need all the puzzle pieces so you concentrate on getting as much done in both realms as possible regardless if the vision changes.

Here lies the Zen of the little Doozers in Fraggle Rock. Regardless of how much those bastard Fraggles munched on their crystal structures – they kept building. They did not bitch or moan, nor be agreeable or argue. They understand the nature of constant motion their little structures take; that is, that they need to stand firm but are expected to be torn down, moved, or changed.

This is exactly what software is – the constant of motion. Do not argue with it. Do not agree with it. Just breath it in and be it and be a Software Zen Master like the little Doozer.