Monthly Archives: September 2010

Why Coding is Not Like Woodworking

Leave a reply

In addition to my opinion that coding excellence is more akin to personal discipline, a la yoga, I think that software has an intrinsic escape hatch/built-in flaw (so to speak).

The feedback loop on software is often simply whether the client was happy with the feature. (Or the boss being happy with the work effort.)

Now, if the developer gets positive feedback even though they might not have coded it as good as an expert, what would drive them to think they need to do better that that? I submit: only an internal drive to push yourself, to stretch your mind, to see if there are alternative ways to do things more effectively. And that is not the norm in most professions, and quite probably not the norm in the software profession.

Most folks are satisfied at doing a “good job” as defined by their “clients.” And why shouldn’t they be?

Were our profession more like woodworking or even music, I think we would have an easier time spotting the difference between a mediocre woodworker, a competent woodworker, and a master craftsman woodworker. In woodworking or music, lousy technique is very evident β€” even to the lay person. From poor design aesthetic, to poor construction technique, to bad finishing.

So, we continue to struggle to show the downstream impact of today’s decisions. How can we improve this?

Why Coding is Like Yoga

Leave a reply

This has been nagging me for a while… like it is an answer, maybe. I’m curious what you might think.

I have sort of determined that writing code is more like yoga, rock climbing, or mountain climbing. It is mostly personal and all about self discipline. Extrinsic motivation has some measure of effectiveness, but I submit that it is largely intrinsic motivation that makes any of us do what we do.

In yoga, it is all personal. I do “battle” only with myself. If I don’t get as much into or out of a pose, i cheat only my own body. So this is like when I am doing relatively isolated coding work on a project. However, when my body or skills are required to be part of a team, now the cheating of my own self can impact others.

For example, when I am working on bits that touch others’ work (common in coding), it is more like alpineering/mountain/rock/ice climbing. The actions of the other guy(s) on my rope will impact me to a great degree (and vice versa). Fortunately I can work with my close buddy and ensure proper protection and that we are making smart decisions. You see, in mountaineering β€” like in coding β€” you constantly need to be evaluating risk, as changes occur every step of the way (literally).

Another parallel to alpineering: My roped team might be fine and dandy and making good progress towards our goal. But believe me, we care a lot about other teams on the same route (for some routes are more crowded than others). Someone else’s carelessness can wipe us right off the mountain. So we are motivated to ensure that other people are safe, or that we are not exposing ourselves to their foolishness. (Ever get “bitten” by someone else’s rotten code?)

In each example, what I do regarding achieving the goal very much depends solely on my commitment to do the right thing. It depends a lot on discipline (hard to always do BDD and not just sling code). It depends a lot on being in good shape and having mental toughness (constantly learning new things surrounding coding). It depends a lot on being able to at once see the big picture (why am I writing this), but also be able to dive deep into the details (down-n-dirty coding).

So, try as we might, there is no way to get around the fact that coding is a individual team sport. Another analogy that might help cement this idea of mine:Β  coding might be closer to gymnastics “team” competition (with individual performances counting a great deal towards the team’s success) than, say, football (of both kinds).

Get your practice on!

Motivational Posters

1 Reply

The sight of motivational posters and laminated “corporate” values posters plastered around the conference room always raises my antennae.

It is frequently a portent of an organization full of well-meaning folks mistaking activity for progress.

Maybe that is why i like de-motivational posters so much 😐

Code City Metrics

1 Reply

Here is a cool “metrics” visualization tool that Thomas blogged about: Visualizing Code Aesthetics

For me, using city layout, while intriguing, might not generate immediate grokking by most people.

It is cool how it shows multiple dimensions by adding

  • blocks:packages and
  • building:classes have
    • footprint based on #attributes and
    • height based on LOC.

I am not sure that people have an automatic reaction to a cityscape that can equate “good code” to a good-looking city. For example, I think most people would say that a good-looking city has a nice skyline with tall buildings grouped in an aesthetically-pleasing manner. That might represent bad code, who knows?

Also, some bad code smells at the class level are

  • All attributes β€” a data blob β€” would be big footprint, low height
  • All methods β€” an overachiever β€” would be tall and skinny

I guess the code cityscape would lead you to see some obvious outliers. But does it tell you much more than that? Does it tell you anything about the “goodness” of the design? Does it tell you anything that a list of computed metrics doesn’t point out with less fanfare?

What is missing in the code city β€” and arguably of greater import IMHO β€” are indications of high coupling, low cohesion; and cyclomatic complexity values (i.e., how convoluted are your LOC).

Nonetheless, the Code City does get your attention as it is pretty cool looking at first glance πŸ™‚

Thanks for sharing!

NOTE: Thomas pointed out that there are some different ways to view the metrics that address some of my metric faves:

Just so you know, there's a bunch of other metrics out of the box:

Color buildings by:
* Brain class
* God class
* Data class

You can also break the classes down into methods (look like floors in
the buildings) to study this:
* Brain method
* Feature envy
* Intensive coupling
* Dispersed coupling
* Shotgun surgery

Agile Bashing?

Leave a reply

On a few different lists, on twitter, and elsewhere, there seems to be some disillusionment with “Agile.”

Here is a great article that outlines the rancor.

Much like pre-Snowbird, in my last few engagements over the past 4 years (just by way of recent examples), I always pushed solving the underlying business problem and providing solutions, as that was what the folks I was talking to needed. It just so happens that I use a lightweight, agile approach. It just so happened that the client was cool with that (and even if they weren’t, I would find a way to do it anyway <g>).

In other words, I did not come in selling agile and accidentally found a project. I was selling being able to help their team solve a business problem and deploy a solution.

One engagement (i was leading the team for about 2 years) was with a company devoid of much effective s/w processes (inefficient waterfall and palpable business/IT schism). Now they have an effective (distributed) agile process, they have a lightweight set of tools, and a good relationship between the business and IT. As agile as I would like? No. But on a scale of 0 to 10, I am very happy that they are probably a 6-7, and even happier that they continue to try and improve. After all, they are in charge of what practices they chose to adopt within their own constraints. I simply shared with them how I have had success doing projects. Some things I suggested we adopt were rejected. Some of those bit the team later — which was a better lesson than had I forced it down their throats.

However, many other times, I think, people/orgs are seeking to just become *more agile.* Or they want their people to be certified in this or that. For some reason, they probably think this will help them succeed. And maybe it will. For me, it is a bit nebulous. I always like to tie all education/training with actual doing so that the lessons would sink in and so that people had a reason to succeed.

Unfortunately, these orgs seeking “more agile” may not necessarily tie the agile transformation to any sort of project success. Rather, they just want to learn better techniques in the hope that it will foster improvement to their bottom line. Sometimes it is just throwing a bone to the folks to try and take their mind off of the truly waterfall world in which they operate.

At times, the agile hype is almost like “If I wear these jeans, I will be buff and have great-looking people surrounding me.” As Madison avenue has brainwashed most of us, that technique is very effective.

Frankly, this is a normal process of a good idea being turned into a movement being turned into a fad being turned into a money-making opportunity resulting in disillusionment and spotty success.

Warts and all, I’ll happily take the rewards that having agile “out there” has provided “humanity” — even if it is abused at times.

The smart and skeptical will prevail and the easily duped will be duped. The beauty of a free market πŸ™‚

Caveat Emptor!