Category Archives: Simplifying Software

Extreme Programming, Simplifying Software

Pondjumpers Podcast Episode #9 is Out

The Pondjumpers podcast is about (agile) software development in open source communities.  It’s hosted by two self-confessed geeks on either side of the Atlantic: Greg Turnquist of SpringSource (the originator of Spring Python and currently on the TC Server team), and Russ Miles of Open Credo (consultants specializing in building open source communities).  Their first hour-long episode came out in June 14, 2009, and they publish a new one about every other month.  It’s available on iTunes or at http://pondjumpers.com, and you can follow them on Twitter at pondjumprs (http://twitter.com/pondjumprs).

Overcoming Delays – No Silver Bullet

Where past episodes have featured interviews with developers of various open source projects, this episode is devoted to a discussion between the two hosts.  One of their main themes this time around is overcoming delays in software development, from delays imposed by the technology to delays imposed by time zones separating distributed team members.  In particular, they discuss how companies looking to “lower the waterline,” increasingly realize that there is no silver bullet — that it’s always a matter of scrutinizing lots of little things.  Shaving a few minutes here and even a few seconds there all add up.  We’re talking about things like speeding up unit tests, speeding up the compile/run/debug cycle, and how long it takes to commit code to a branch and then merge it into the trunk.  These kinds of time savings make the difference between being able to consistently deploy new code to production in terms of days and weeks rather that weeks and months.

On a related subject, Turnquist and Miles stress the importance of automated continuous deployment (not just continuous integration) complete with “smoke tests.”  Another topic covered is the popularity of distributed version control and, specifically, the trials and tribulations of moving from Subversion to Git.

If Pondjumpers resonates with you, then keep an eye out for a new podcast series that Russ Miles is involved in producing for Open Credo.  It will feature screencasts and videos devoted to, as Miles boldly puts it, “software development in the real world.”  For this endeavor, Miles is aiming to focus on interviews with “honest, no-holds-barred doers.”

Events, Simplifying Business, Simplifying Software

Simplicity Appreciation 101

1 Comment

If you happen to be near Raleigh, NC on December 7th, I’ll be speaking at the local Agile developer’s group while I’m out there on business.  The title of my speech is “Simplicity Appreciation 101,” and here’s the synopsis…

Update: Due to a scheduling conflict, I was not able to deliver this talk in Raliegh, but I did present it at the Fullerton Code Camp on January 29th. The slides are available for download on the Downloads page.

Complexity is insidious.  It creeps in and takes hold and doesn’t let go.  Time and again, we see major undertakings fail due to overwhelming complexity.  That’s why proponents of Agile methodologies all tout the virtues of simplicity.  “Do the simplest thing that works.”   “YAGNI.”  “KISS it!”

But what exactly is “simplicity?”  Can it be dissected and described?  In many ways, simplicity is ethereal and personal, gleaming only in the eye of the beholder.  But, yes, it can be broken down and viewed with an objective eye.  In this presentation, we’ll explore dozens of examples of simplicity from the realms of software development, business enterprises, and life, in general.  We’ll look at specific cases of simplifications as well as tools and techniques recommended for achieving simplicity.

Our starting point will be ten observations about simplicity by an MIT professor named John Maeda.  In his book, “The Laws of Simplicity,” he describes how simplicity relates to size, time, context, emotions, trust, and more.  These revelations alone provide a solid foundation for making better decisions to achieve simplicity, but, time permitting, we’ll also consider the nuanced wisdom of Albert Einstein, Mark Twain, Winston Churchill, and others.

For further information about this event, see the group’s MeetUp page: http://www.meetup.com/agileRTP/

Scrum, Simplifying Business, Simplifying Software

Prudent/Inadvertent Technical Debt

On the subject of Technical Debt, Martin Fowler identified a TechnicalDebtQuadrant in which technical debt is classified as either Deliberate or Inadvertent and either Prudent or Reckless.  He then makes the case that software projects can reasonably see all four combinations, including Prudent/Inadvertent — even though he can’t think of a real-word analogy that can be used to describe it to management.

How about this? Continue reading Prudent/Inadvertent Technical Debt →

Extreme Programming, Simplifying Software

Taking the Stick

A front page story in this morning’s USA Today talked about airline safety and how improper simulator training for pilots often causes accidents.  Flight simulators, no matter how impressive the technology behind them, are not perfect representations of actual flight.  Yet, the airlines rely on them for the bulk of new pilot training.  So, under certain circumstances, pilots take the wrong actions because they react to how the simulator works, not to how the plane actually works.  This is proof that the old adage “practice makes perfect” isn’t quite right.  The saying ought to be: “practice make permanent.”  Practice the wrong things, and you just get good at doing the wrong things. Continue reading Taking the Stick →

Simplifying Business, Simplifying Life, Simplifying Software

This Simplification is a Lifesaver (literally)

Somebody at the American Heart Association figured out that, in most cases, CPR can be just as effective if only the heart-massage part is done, without the breathing part, and that hands-only CPR is WAY better than doing nothing. So, they’ve launched a campaign to spread the word, complete with how-to videos and smart-phone apps.  See http://handsonlycpr.org/.

This is a drastic simplification, and there’s a big lesson in this for us Agilsts. Continue reading This Simplification is a Lifesaver (literally) →

Scrum, Simplifying Business, Simplifying Software

User Stories: It’s SMART to INVEST

The basic framework for a good user story has 3 parts: identifying which user/role (or other stakeholder) benefits, what that person wants (the goal), and the payoff (why it’s important).  You’ll often see this framework expressed as the following template: “As a ________, I want ______, so that __________”.   To paraphrase Mary Poppendieck’s quintessential requirements example,

“As the VP of Distribution, I need us to redesign the REAR windshields of our cars to withstand wind-speeds of up to 130 MPH (as our FRONT windshields already do), so that we don’t have any more accidents when our cars are loaded onto transports facing backwards and then hauled at 70 MPH into a hailstorm with headwind gusts of 50 MPH.“

Since the second blank represents a goal, a lot of user-story writers find the SMART mnemonic helpful.  It’s one that’s taught in traditional goal-setting seminars, but as you can see, there’s no consensus on exactly what the mnemonic stands for:

Specific / Significant / Stretching
Measurable / Meaningful
Attainable / Achievable
Realistic / Relevant / Reasonable
Time-bound / Testable / Trackable

So, a better mnemonic that’s especially pertinent to user-stories is INVEST (think “Return-on-INVESTment”): Continue reading User Stories: It’s SMART to INVEST →

Extreme Programming, Simplifying Software

Test-First Development Can Be Liberating

Experienced agilists talk about becoming “test infected.”  For everyone, unit testing starts out as a chore that seems like it’s more work than it’s worth, but then you get over a certain hump and suddenly unit testing is a breeze.  The benefits become manifold and profound, and you begin to wonder how you ever programmed without it.

One important milestone on the way to achieving test-infected enlightenment is the transition from test-after to test-first.  All developers start out writing the production code first and then write unit tests around it.  It’s the only way we learn.  But, eventually, we begin to see the power of writing the tests first.  This used to be called Test-Driven Development, but it’s more accurately referred to as just Test-First Development (although we still abbreviate it as TDD).

For me, the greatest thing about TDD is that it gets the subjective part of the problem out of the way early, leaving just the objective part to puzzle out.  “Okay, now that we know what we need to accomplish, we just have to get it to work.”  It’s a rather liberating feeling. Continue reading Test-First Development Can Be Liberating →

Extreme Programming, Simplifying Software

Lessons in YAGNI

YAGNI stands for “You Ain’t Gonna Need It” (yet).   It’s a mnemonic meant to remind us developers not to speculate. That we should only put in code that addresses the task at hand and worry about tomorrow’s challenges tomorrow. There are many good reasons for this advice, the chief among them being that situations may change between the time that the speculative development happens and the need for the feature actually arises. In that case, the speculative development will turn out to have been wasted development time that could have been spent on addressing more immediate problems.

I thought I had learned this lesson years ago. I thought I was pretty sensitive to YAGNI and had a good track record for resisting it. But, recently I introduced a bug in a system that I was working on, and the ultimate reason for the bug is that I had committed the “crime” of speculative development. Continue reading Lessons in YAGNI →

Pragmatic Marketing, Simplifying Software

Is the User an Expert or a Novice? It Depends

Pragmatic Marketing LogoI posted earlier that Barbara Nelson of Pragmatic Marketing will be one of the presenters at ProductCamp this Saturday. When a company I was working with six years ago hired Pragmatic Marketing to teach everyone their system, it was a definite game changer, and she was the one who taught the course.  For my part, as a software engineer, I learned from her how to work much more closely and effectively with the marketeers.  The insights we all gained from Pragmatic Marketing’s experience were invaluable.  They are lessons that I continue to apply every day.

As just one tiny example, I’m reminded of an Aha! moment I experienced back then. It was the notion that novices don’t typically stay novices for very long. Continue reading Is the User an Expert or a Novice? It Depends →