# April, 2008

Posts
• #### Being greener

For most of my life, I've been a "small e" environmentalist. I'm not outspoken on my views, but I really hate to see needless waste. For me, that's meant keeping cars for a long time rather than replacing them, spending a little more on stuff that will last so I don't need to throw as much stuff away, and getting books at the library. Stuff like that.

I haven't, however, put as much effort into applying the same principles to my profession, and over the past few months, I've been working to be more reasonable in that area as well.

I've come up with a few practices that I thought I'd pass along, as part of what I'm calling "Green Programming - Simple practices to make the world a better place..."

Practice #1:

Consider the following code:

if (x > 5)
{
i++;
}

Now, if I need to change it so that 2 is added to the value of i rather than one, I would probably do the following:

First, I'd select the line with the increment:

if (x > 5)
{
i++;
}

hit "delete":

if (x > 5)
{
}

and then type in the new line:

if (x > 5)
{
i = i + 2;
}

I've done that sort of thing millions of times in my career. But not any more. Here's what I do now:

First, delete the characters that I no longer need. In this case, it's just the second "+" sign:

if (x > 5)
{
i+;
}

then, insert " = i "

if (x > 5)
{
i = i +;
}

and finally, " 2":

if (x > 5)
{
i = i + 2;
}

In my first version, I deleted 12 characters (plus a carriage return and linefeed), and then added 20 new characters. With my new approach, I deleted 1 character and added 7 characters. That small change reduced my deletion percentage by 91.67%, and my new character percentage by a less impressive but still impactful 65.00%.

Practice #2:

The first practice made some great improvements, but I thought there was more to be had. I found that I could keep open a session of notepad, and rather than deleting the characters from my code, I would copy them to notepad, for possible reuse later. Unfortunately, since I write a lot of new code, I tended to exhaust this resource fairly quickly, and was forced to fall back on typing new characters.

Practice #3:

To give me a better source of recycled characters, I came up with a new approach. Not only do I copy characters to notepad before deleting them, when I need to delete a source file, I copy *all* of it's contents to my notepad buffer before deleting the file.

I am proud to report that I now am justified in believing that I am "character neutral" in all of my coding. That made me quite happy, until I realized that I still had a problem.

It was my blogging. I tend to write a fair bit on my blogs (3-5 depending on how you count them), but because of my natural eloquence and low quality standards, I rarely delete stuff, and therefore keeping a buffer for my blog writing was problematic. I tried using my programming one - it certainly is sufficiently full that it won't run out quickly - but I found that I tended to have some problems with expression ("I regret I have but one life to give foreach my country"), not to mention developing having to write lines like this:

(){=();="");(<,>){=.;=..;=..;<>=<>();(());(..()){=;}}

to use up some of the excess punctuation.

So, that clearly wasn't workable, but just yesterday I came up with a great idea. I'm now recycling all the contact spam that is *already generated* by my blog into my blog buffer, and I'm considering re-using the splog links I keep getting, which would be especially convenient as they already have the words that I like to use.

So, that's my little contribution, because as I like to say, if you're not part of the solution, you're part of the problem. Or the precipitate.

Future Ideas:

I haven't thought all of these through fully, but here's a list of other ways you might "recycle and reuse":

• Don't throw away that command window you're using and create a new one. Reuse the existing one.
• Keep old classes around to use as the starting point for new ones.
• As some believe in "Peak Oil", I fear that we've already reached "Peak Guid", and that the days of \$4 guids are in sight. I therefore recommend that you save all of the guids that you generate. Sure, it may be 15 years before the software that you used them in is gone and you're free to reuse them, but if you're the guy with 500 guids in your pocket during the Guid crisis of 2025, you're going to be sitting pretty.

(composed of 100% post-consumer characters)

• #### HealthVault Vocabulary Browser

I wrote a little utility to browse vocabularies that I thought you might be interested in.

It uses the HelloWorld app id, so you should just be able to dump it to a directory and run it.

If you just want to browser, you can do it on the labs vocabulary page, or the vocabulary browser on Get Real's Developer's x-ray tool.

• #### Individual Empowerment and agile...

(Interestingly, I find myself writing more about agile and team stuff now that I'm not on a development team....)

This is in response to a question about how you balance individual empowerment with the collaborative approach on a agile tem...

***

Agile is all about the team, and being on an agile team requires participants to give up some autonomy towards the team. The team is empowered to do what they need to do to reach their goal. If there are issues around how things should be done or what decision is right, the team needs to come to a decision, and I would encourage management to let the team try to do it.  Further, the team needs to “meta rules” around how to make decisions, and they also need to develop those.

This is very different than the “alpha geek” culture that exists in some groups, where a small number of developers are interested in wielding power. There are some individuals who just aren’t willing/able to work collaboratively – I’ve worked with a few, and if you are trying to run an agile team, they are likely better in a different position.

One of the teams I was on basically came to this agreement:

Developers are expected to use their best judgement when deciding what advice to seek when they are doing development.   There are no rules around when you should seek advice, but as a rough guideline, extending functionality under existing patterns is something you can safely do on your own, and big refactorings or new components are areas when you should definitely seek advice. In between, think about the implications of any design choices you might make, and act accordingly.

The other approach is to adopt pair programming, which is a bigger cultural change, but generally if you get two people thinking about decisions they usually make the right decision about involving others.

Page 1 of 1 (3 items)