Jun 152011

What is it to “produce”, specifically in the domain of software?

We speak of productivity in business all the time, so let’s start by linking productivity with “producing” and “production”.

The Theory of Constraints, a production system most often linked to manufacturing, uses three metrics – inventory, operating expense and “throughput”.

Though the first two are not as obvious as they may sound (and are topics for other posts in the future), “throughput” is the rate at which a system produces “money” (or products we can sell, or software we can ship to a customer).

Now, you may remember I am a proponent of agile software development.

There are some great philosophical parallels between ToC and tenets of agile, but one thing I want to focus on is what helps us move toward our Goals and what shows up as constraints from reaching them.

Shipping quality software, fast

What does it take to focus on the prize and ship valuable and high quality software as fast as possible?

Without writing out another agile manifesto, here are some fundamentals (in “Faw’s Laws” format, and not necessarily in order):

  1. Coordinate, communicate and collaborate with your teammates and customers recurrently
  2. K.I.S.S. – “steer the ship” in small increments with your eyes on your end goals (shipping quality software, fast… remember?)
  3. Give your team and your customer plenty of feedback on your progress in as low-cost a way as you can
  4. Don’t pretend to know everything up front, or that things won’t change along the way
  5. Team trust – you have to know your teammates have your back, and you’ve got theirs
  6. Avoid, minimize and/or eliminate rework – let’s not waste the precious hours of our lives
  7. Automate tedious tasks (testing, build, etc.) to remove manual errors/omissions and cut overhead time
  8. If you want to reduce the need for brittle documentation, draw pictures and don’t forget to write logs
  9. “Those who say it is impossible should get out of the way of those doing it” – a favorite quote (not sure where it originated)
  10. Umm… and a pet peeve – be suspicious of null pointers and poor exception handling (I couldn’t leave these out)

My primary concern in writing these out is to maximize throughput while simultaneously minimizing “inventory” and “operating expense”. Again, we may talk about those two later on.

Whichever development method you embrace, your tactics are likely to be oriented around achieving more fundamental interim goals like these.

What others would you add to the list? How would you frame your objectives differently?

  21 Responses to ““Producing” Software”

  1. One that I think is important (and one of the traits I do appreciate about your approach to development that we seem to share) is to work from the target audience, particularly the interface backwards. You actually mentioned this on the first or second day we worked together and I remember getting a little smile inside because too often I feel like I have to preach this to others. If your target audience doesn’t find it “easy” to use or doesn’t give them a sense of gaining productivity, they not only won’t like it but will most likely look for opportunities of not using it. It’s important to raise the questions of concerns with the users to make sure the app is providing the goal intended, but too often we’re so entrenched in the code that we don’t consider the user experience as well.

  2. Thanks, Moose.

    XP calls what you describe a part of “Metaphor”. When people have a similar mental model of the software product, everything runs a little smoother. Of course, thinking we have a shared metaphor when we don’t can lead to breakdowns, so that is where recurrent low-cost feedback is great.

    What else triggers you?

  3. That’s very true. Thus why it’s so critical for everyone to be on the same page for agile development to be successful. Commonality in vision is imperative.

  4. I also look at agile as a place for building people up. We may not be on the ‘same page’ when we start working together. What becomes common is the fundamentals and the vision, but we can preserve our individuality and our strengths.

    • Absolutely. I a long time ago, in a galaxy not too far away, I was a beginner learning Java. I had the privilege of working alongside an extremely talented individual in a pair-programming environment and learned more in a few days with him than I could have done by myself.

      I personally enjoy “paying it forward” working with people just starting out in their careers and helping them to be more productive and effective, watching their eyes light up with understanding as they begin to “get it”.

      • Shucks, for a minnit’ there I thought I might have been the ‘talented individual’. We had a lot of great folks back in the day, huh?

  5. Somewhat related to what Moose has already written, I think it is imperative, when practical, to get the voice of the people who will actually use the software involved early and often. Developers, product owners and management all think they “know” what they want and/or need, but at the end of the day, if it does not actually help those who actually use the software, why was it written in the first place?

    I accept that sometimes even those who will use the software on a day to day basis don’t know what they really need — it is up to us as technical leaders to provide our thinking and design with them to produce a valuable outcomes.

    • Yep, I was concerned about writing too much in bullet #1, so I left it at the bullet. I like your choice of terms “imperative, when practical”… WHAT? That sounds like the title of a new blog, or at least a post, for rickswrong.wordpress.com… I will work on that one this weekend!

      Seriously, so much of what you are saying relates to having a good handle on purposes/outcomes/objectives as well as a means for communicating effectively (which is not the same as endless meetings or epic documentation).

      It ultimately comes down to communication, and where software is to some extent the artistic expression of rules expressed in code but interpreted from language, there is so much room for mis-communication that it deserves as much attention as it gets.

  6. […] XP, SCRUM or any other approach… or even agile in a way, I was more concerned about shipping quality software that the market valued highly as quickly as possible. A development team or larger department adopts a way of doing things that includes various […]

  7. Ken,

    Thank you for the post and for the thinking you triggered in me.

    “Producing” software for the sake of what would be my question. Why is “fast” important if the reason why you’re producing it is flawed to begin with? More times than not, the weak link in the process is in the User Story itself. It brings forth the inherent weakness in Agile . . . it is concerned with simply getting things done when there is so much more to the process than Shipping Quality Software, Fast. I think this requires a blog post of my own.

    • Thanks, banky, for your assessment.

      Where my distinction appears to differ from what you are describing is in the notion of “quality”. Is it quality software only if it is free from defects? Not in my book.

      To me, quality is a distinction in the domain of trust production. If we consistently and recurrently ground our assessments of value in the interpretation of our customers, then we would not craft a user story that will not be valued, and we will not implement the user story if it is not a priority of our customer. Trust is a key mechanism in effective agile too often glossed over.

      I accept your assessment as a breakdown in trustworthiness and weak interpretations of agile, not a breakdown in agile as an approach. Make sure and link your new post back here so I can jump into your conversation!


  8. […] Information technology and software teams are all about managing resources, especially with a view to productivity. […]

  9. […] am writing about value today because of questions that arose from my earlier post on producing software, in which I summarized an objective of agile to produce quality software, […]

  10. […] them, what actions could you be taking to relax those constraints a little? In what ways can you prevent defects or breakdowns from recurring? Do you have a team or someone in leadership who supports “stopping the machine” long […]

  11. […] with each other, engage with each other, make and fulfill promises to each other, sounds a lot like software production and the day-to-day function of an information technology […]

  12. […] am writing about value today because of questions that arose from my earlier post on producing software, in which I summarized an objective of agile to produce quality software, […]

  13. […] I mean, rather than worrying about whether I was officially “doing” XP, SCRUM or any other approach… or even agile in a way, I was more concerned about shipping quality software that the market valued highly as quickly as possible. […]

  14. […] producing software is our main objective, then we come up with distinctions to help communicate and coordinate that […]

  15. […] than one release allows notions of “good enough” or “done enough” to start producing business value quickly even when some defects are known to exist or some features are not fully […]

  16. […] that my first and highest concern relates to what we produce in software, systems, reports and automated processes for business consumers. I don’t intend to call out […]

Leave a Reply