“Producing” Software

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?

Advertisements

About ken
Creative insights, passion and technical adrenaline - strategist, agile coach and marketer, providing a good life for wife of 20 years & 2 awesome teenagers!

16 Responses to “Producing” Software

  1. bfmooz says:

    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. ken says:

    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. bfmooz says:

    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. ken says:

    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.

    • Rick Ross says:

      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”.

      • ken says:

        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. Rick Ross says:

    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.

    • ken says:

      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. Pingback: Should you care if your projects are agile? « kenfaw.com

  7. Pingback: Don’t mistake being costly with “job security” « kenfaw.com

  8. banky says:

    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.

    • ken says:

      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!

      –k

  9. Pingback: Mankiw’s “10 Principles of Economics” and information technology « kenfaw.com

  10. Pingback: Who says what’s valuable? « kenfaw.com

  11. Pingback: What were we thinking? « kenfaw.com

  12. Pingback: Principles of IT and software a la Mankiw « kenfaw.com

%d bloggers like this: