constructive nonconformist

A Design Problem ...

A design problem is not an optimization problem.

— Christopher Alexander, quoted on Projectionist

SOA: Time For a Rethink

We need loosely-coupled services, not orchestration.

… the key really is to “Test fast, fail fast, adjust fast.”

— Michael Nygard
Wide Awake Developers: SOA: Time For a Rethink

Do You Talk to Your Compiler?

Do you talk to your development tools?

On Emeril Live, Emeril Lagasse would sometimes make funny little humming noises as he worked. I found it charming in a dorky way. Emeril’s example makes me feel better when I catch myself talking out loud to my compiler.

Urgency is Poisonous

… in the software industry urgency is self-imposed and morale-busting.

— Jason Fried
Signal vs. Noise: Urgency is poisonous

Successful Large Systems

There is a rule of thumb that says that every successful large system is a development of a slightly smaller working system. You apply that rule recursively.

— Bjarne Stroustrup
Artima: Elegance and Other Design Ideals

Professional Praise

Here’s a story:

I’m working as an in-house software engineer for Nameless Big Co creating software for internal use.

I’m at an all-hands meeting for my business unit group. A very important person in a nice expensive suit is at the podium. Apparently we’re honored to have him come and speak to us. What he has to say is engaging until he gets to a certain point.

He tells us he’s had a career in financial services IT and we’re the best and brightest IT organization he has ever worked with. I think of the inefficiencies and poor decisions we deal with every day. It’s normal stuff for a large organization and for a software development management chain heavy on MBA’s. I don’t think we’re more clever than average.

Why is Mr. VIP laying on the superlatives? Is he out of touch? Is he measuring differently? Is he just trying to be a cheerleader? Is he marketing to us?

Striving to be the best and the brightest is incompatible with being uncritical enough to accept his hyperbole. I tune out. He’s pushing more noise than signal.

Here’s a second story:

The lead architect has moved some of my code from a particular project down into a core library so he could use it on another project. “You saved me a lot of time.” He tells me. “You did some good work on that project and I want to leverage it across the other projects.”

Here’s a guy whose technical chops I respect and he found my code useful. It’s a small thing but it made my day.

Peer praise is meaningful.

Joy in the Job

Ponderous Programmer: Crazy is as Crazy Does - Joy in the job

The human programmer

Coderspiel: The human programmer: "Here’s a theory of software quality for you: software must be nurtured."

(Via raganwald.)

Links

Ponderous Programmer: Crazy is as Crazy Does - Joy in the job.
kirit.com: JavaScript garbage collection.

Code Life

The sphinx riddled "What walks on four legs in the morning, two legs in the afternoon, and three legs in the evening?" The answer is man. Man crawls as an infant, walks as an adult, and uses a cane as an elder.

I was noodling with the idea that a code base passes through phases of life.

For a new project with a clean slate choices are relatively unbounded but initial features can take some time to develop because there's little or no infrastructure yet. A new code base must crawl before it can walk.

As a code base matures feature implementation should become easier. There's something to build on. There's code that can be reused. A healthy mature code base is a sweet spot.

However when we are not good stewards a code base can develop infirmities. The code can become stiff and brittle where it should be loose and flexible. Or it may become bloated and confusing where it should be lean and literate. Fortunately (and I'm really stretching the analogy now) a code base can be rejuvenated.

What do you think? Useful idea or just silly?