Lazy Developer plus No Slack equals Funding Guilt

I have enough hubris to consider myself a lazy software developer. I also work in an organization where there is not a lot of slack. Overall, I consider myself very blessed to be a part of the software group in which I work. There are many intangible rewards that I receive personally by working on the projects I'm assigned to work on.

Most of what I wanted to say in this article has already been said, so I'll spare you the effort if you're already well-read in this area.

However, the lazy developer / no slack combination often produces an interesting set of emotions within me. In particular, I repeatedly feel a certain ugly kind of frustration.

Here is my shot at defining this certain kind of frustration:

Funding Guilt: n. The feeling of having a sense that you could solve the problem at hand in a better way and more conveniently by inventing a solution to a more general problem, but being in a position where the investment in that more general solution is not specifically funded by the person paying for the specific assignment and might be more costly in the short term.

A lazy developer's answer to this is often to ignore the context and solve the more general problem anyway, with an eye toward paring the problem down to its core and avoiding gold-plating.

I remember working with a very smart developer who told me he kept an open critical bug as cover for getting real work done. If asked what he was spending his time on, he would point to his efforts to solve the critical bug. He would make enough progress on the bug over a period of time that people would continue to leave him alone, because they really wanted the bug fixed as soon as possible. But he devoted a significant amount of his time each day toward his real work. And when that bug got fixed, he'd pick up another serious bug that looked like it could be of use. Maybe this approach could be called "Bug Cover".

Although that approach to avoiding funding guilt is deceptive at its core, it worked for him. I'd prefer a way to avoid funding guilt that was more above board.

And perhaps funding guilt only appears in hyper-responsible people, of which I am one.

For those of us who feel it, acknowledgment of this emotion sometimes helps create a sense of understanding and perspective in ourselves and others, including possibly sponsors of our work. It is important to be able to forgive oneself for funding guilt if solving the more general problem is really the right thing to do. But this is not a resolution to the core question. How can funding guilt be avoided as a matter of course?

Maybe it's a matter of choosing very carefully which projects you work on, or at least aborting unfruitful projects very quickly.

Maybe the proper response to expressed funding guilt is at the core of the art of great software management. Perhaps great managers are those who can create the sense of slack that is needed to allow developers to get their juices flowing and create great stuff.

Even if it does involve a little cover.

P.S. FWIW, many of the ideas in this post come from having read and digested the following:

• Pragmatic Thinking & Learning (personal learning)
• Driving Technical Change (organizational rollout affordances)
• Mythical Man-month (multi-pass thinking)
• using Git on a daily basis (multi-pass thinking)
• Pay to Learn when playing the game of software (optimizing for learning)
• Sooner Not Faster (optimizing for learning)
• Reductionist Agile Manifesto (paring things down to the core)

Heralds of Life

My sister, Ann Sumsion wrote the following poem on Thursday, and I asked her if I could post it here. She said yes, so here it is:

Heralds of Life

Daffodils, the Trumpets of the Lord,
Speak peace and courage, love and faith,
To souls cold in world's winter.

Their warm and yellow blooms
Are testament of His enduring Grace
And Tender Mercies.

They cry, "The Lord is my Light,
And my Strength, and my Song.
He is my Salvation."

Heads bowed in strong Humility,
They nod in gentle breeze and bend in mighty tempest.
As leaves of grass, they die and fade,
In heat of summer's day.

But the memory of their bright nodding heads
Brought back in dark of night, and chill of frost,
Recalls Life, death overcome.

Their clarion trumpets echo their Master,
And cry, "Spring forth,
And Rise again."

I'm grateful for Ann's friendship and love for me. Her love for and confidence in her Savior are also qualities that I admire in her and want to emulate.

These things transferred to myself

Paul said (see 1 Cor. 4:2-6, emphasis mine):

Moveover it is required in stewards, that a man be found faithful.

... yea, I judge not mine own self.

For I know nothing by myself; yet am I not hereby justified: but he that judgeth me is the Lord.

... And these things, brethren, I have in a figure transferred to myself and to Apollos for your sakes; that ye might learn in us not to think of men above that which is written, that no one of you be puffed up for one against the other.

Nephi said (see 1 Ne. 19:23, emphasis mine):

but that I might more fully persuade them to believe in the Lord their Redeemer I did read unto them that which was written by the prophet Isaiah; for I did liken all scriptures unto us, that it might be for our profit and learning.

I see the following three ideas present in both statements:

1. habit of personalizing scriptural teaching
   
2. attempt to teach by example
3. making reference to prior patterns of personalization in a teaching situation
   

These scriptures are filled with a refreshing spirit of no-nonsense, concrete, step-by-step spiritual teaching. The teachers' attitudes are unassuming and direct.

I've been in teaching/learning situations like this, and it feels really good to have a teacher that both understands the material and is willing to put it on your level when explaining it.

I'm grateful for Paul's and Nephi's willingness to be as frank and humble as they were in these scriptures. It's been a blessing to me to read, compare, and contrast the two scriptures.

Core Goals of Version Control

After having a couple of years of experience with Git, I was finally able to clearly articulate the core value that version control brings to software development. This article will be written with a bias toward Git, but I've at least tried to express the core value in abstract terms.

The value is expressible in 4 goals.

Core Goals

1. Capture source artifacts
2. Isolate stable codelines from WIP
3. Enable concurrent WIP
4. Make it easy to leave sensible history behind

WIP = Work In Progress

The continuous delivery crowd says that WIP should be basically zero. I think that there is space for a fairly short development pipeline (3-5d) that can free developers up to capture ideas and then wrangle them into shape in a second or third pass.

Capture Source Artifacts

As a developer, I feel happy when I can push a save button when I've taken a small step -- and then never have think about it again. I also feel happy when I can save, even if I'm based on a slightly out-of-date base. I also feel happy when I don't have to worry about binary vs. text -- as long as its a true source file of a reasonable size.

I feel happiest when I don't have to be distracted by superfluous concerns, and can focus on the task at hand and save the results easily.

Main Point: A good version control system makes it easy to capture source artifacts.

Isolate Stable Codelines From WIP

Software is hard to get right, and once things get stable, the only way to keep them there is to avoid making risky changes. But stability is always balanced against the common desire for enhancement and restructuring.

A typical bug fix is one or two isolated commits that fix a specific problem. Most version control systems more or less support cherry-picking a small change over into another codeline.

I feel happy when I'm able to easily take an isolated series of commits from the development codeline into a stable one, even if the fix turns out to be a little larger than a couple commits.

Main Point: A good version control system makes it easy to cherry-pick changes, and even longer patch sequences, from one codeline to another with easy reconciliation of overlapping edits.

Enable Concurrent WIP

For software developed by a team larger than 2-3 people, it is useful to be able to work in parallel with each other, even on the same feature. Sometimes you can arrange your work so as not to overlap at all, but there are real situations where you want to track someone else's development within the fairly short development pipeline (3-5d) before things have gotten stable.

I feel happy when I don't have to catch people up on what I've been doing, and when they don't have to catch me up on what they've been doing, and we can get to the point easily and quickly. I also feel happy when we can leap-frog each other with ideas and real implementation.

Main Point: A good version control system makes it easy to track other team members' work, and easy to tentatively integrate with that work.

Make It Easy To Leave Sensible History Behind

After stepping away from a piece of software, it is easy to lose context and forget the concerns that shaped the development of that software. It doesn't take long. For me, about 2 weeks is enough for me to start forgetting details and motivations.

Of course, it is important to leave a properly structured artifact behind. Proper naming means a lot; proper factoring is important. Once you comprehend the structure, it is possible to change things without introducing big problems.

But often, full comprehension isn't practical, and a flat 2D view of the artifact is insufficient for reasoning about the thing itself. Often, it is often very useful to be able to get a vector on where the software came from, and interpolate from that vector where it was headed.

The creative process is messy, filled with double steps and backtracking. Don't confuse me with all the noise. Give me a history that, given all the knowledge you had when it got stable, at least looks well-reasoned.

I feel happy when I'm able to take an easy editing pass following capture/review that lets me intentionally craft history as an email to the future about the vector of change that is inherent in a certain patch sequence. I also feel very happy to not have to think about this during the creative, messy, focus-draining capture/review pass.

Main Point: A good version control system includes tools to both: 1) enable the developers to easily leave behind meaningful history, and 2) extract focused history for all or part of a piece of software.

AN: Innovative genealogy information graphic

Yes, RootsTech was a month and a half ago, but this was important and I need to write about it.

I went to the lightning talks at RootsTech and saw a 5m presentation from Antoninus Niemiec, an MFA student from New York working on genealogy visualization. He called his presentation "Not Your Father's Chart".

With permission, here are two fuzzed views of the charts so you can get the overall picture.

Plate A is a traditional ancestry chart:


Plate B is the same ancestry, laid out in this new and innovative way:


Here is a close-up of a given family:


Antoninus presented a very innovative information graphic of a 5 generation ancestry. At a high level, his work is firmly grounded in Tufte's information graphic design priciples. There were no wasted pixels and no chartjunk, just content.

It was organized with a radial feel to it, with the descendant family clusters in the center, and ancestor family clusters radiating outward toward the edge of the page. Each family cluster was organized into two tree-rings, one for the father, one for the mother-and-children. Each tree ring meant a decade, birth and death dates were plotted on a 360 degree circle, angle determined my how far into the year the event happened.

He told me he is working on publishing this work on his website. He said he did it in Adobe InDesign using Javascript with some hand-tweaking afterwards.

This spawned an interesting conversation afterward about the possibility for a visualization challenge for RootsTech 2012:

• fixed content corpus
• released shortly before the conference
• awards in traditional media (print, web, video)
• award for most innovative visualization, regardless of format

BTW, this was the same lightning round that Tevya talked about.

Flesh pots & Resistance to change

I was reading the account of Moses leading the Isrealites out of Egypt. After all of the miracles that accompanied the exodus comes the account of the net sum response of the Isrealites (Exodus 16:2-3):

2 And the whole congregation of the children of Israel murmered against Moses and Aaron in the wilderness:

3 And the children of Israel said unto them, Would to God we had died by the hand of the Lord in the land of Egypt, when we sat by the flesh pots, and when we did eat bread to the full; for ye have brought us forth into this wilderness, to kill this whole assembly with hunger.

I'm sure that my response to inspired leadership has sometimes sounded like this. And I'm very much willing to both admit that and abandon that position.

In stark contrast, is the message contained in Pres. Henry B. Eyring's conference talk, Trust in God, Then Go and Do. In particular, another scripture comes to mind (1 Nephi 3:7):

7 And it came to pass that I, Nephi, said unto my father: I will go and do the things which the Lord hath commanded, for I know that the Lord giveth no commandments unto the children of men, save he shall prepare a way for them that they may accomplish the thing which he commandeth them.

Willingness to move forward and change and follow inspired leadership is a quality that I value, and that I seek to emulate & encourage.

Published with Blogger-droid v1.6.7

Excited for MWRC

I am so stoked for MountainWest RubyConf this year. Last year was great, but I can feel it in the air that this year is going to be sooo much better!