My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Making goals and achieving them - overcoming adversity to gain something you want - is tremendously motivating and often rewarding in life. Still, there are often times you extend so much effort in focusing on the goal that you don't notice the journey, or worse: you make the journey downright unpleasant.

That's the discussion in this week's chapter from Chad Fowler's MJWTI.

The point revolves around the fact that hitting the goal is short-lived, while the process of getting there takes up the bulk of the time. Therefore, wouldn't it be better to view the process as the goal itself, and make that the enjoyable part?

My view diverges from Chad's here. Whereas he implies that this observation is a better way to live generally, I tend to think it applies to particular people doing particular things. For instance, I might agree that, in general, the US is "a nation of people who are always focused on the outcome of a process," I wouldn't agree that it's "one of America's biggest problems" (Quoting Chad Fowler, pg. 156). Still, I might be more inclined to think that people's choice of goals doesn't line up with my own.

Regardless of the small divergence of our beliefs about the theory in general, I do agree that it works for software development. I'm not talking about doing software development as a means to achieve fame, fortune, girls, and cars (or just as a means to do something else with your life). For the production of software as a means to reach goals (including some where the path is the goal), I agree with Zed Shaw:
I've been saying for years that you can live a life involving code and hacking as a cultural phenomenon, but you can't live a life that only has code. You can work and make money doing web programming, but you can't make a life out if it. I try fill my mind and experiences with other shit, and then use code as one of many ways to express myself.
Those kinds of goals are rewarding long after you've achieved them. Memories last until you forget them, and you can drive that Ferrari convertible up and down the Pacific Coast Highway until it falls apart.

Red Ferrari convertible

Ferrari wrecked on the Pacific Coast Highway

But if you're talking about finishing a project as the goal, then you're likely to put yourself in a lot of pain during the journey.
Back to the software development example, it's easy to get wrapped up in the delivery of the code you are creating. Your customer needs a web application up, and you focus on finishing that application. But, a living application is never "done." One release leads to the next. Too much focus on the end product distracts us from the real deliverable: the sustainable development of a new entity.

Focusing on the ending makes you forget to make the process good. And, bad processes create bad products. The product might meet its minimum requirements, but its insides will be ugly. You've optimized for the short-term end goal -- not for the inevitable, ongoing, future of the product's development. Not only do bad processes make bad products, but bad products make bad processes. Once you have one of these products that is messy inside, your processes adapt around it. Your product's broken windows lead to broken windows in your process. It's a vicious cycle.
Sound familiar?

It does to me. A focus on a ridiculously short promised delivery date leads to no tests leads to coupled code modules and "quick and dirty" hacks in the code. That leads to an inability to test and more hacks in maintenance. And the cycle continues.

Wouldn't it be better to treat the process of making applications as the goal to be enjoyed, rather than masochistically torturing yourself?

A leather paddle, with which to torture yourself.

What's your experience like? Are you more likely to treat the end as the goal or the path? Which works better for you?

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 Cplusplus (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