The Continuouses

I love creating software! I want to deliver business value efficiently over time. I’ll share my thoughts with you on what it takes to carry out that. This blog post is about continuous processes, which of them I feel are the most important ones and what their added values are. Finally, I will talk about the one continuous process to rule them all, find them, bring them all and in happiness bind them. Yeah, don’t you already desire it? Anyways, I hope to provide you with a slightly different approach and perspective to software development and maintenance. By the way, this is my English version of my original blog post written in my native language, Norwegian.

The Continuouses

  • Continuous Feedback
  • Continuous Integration
  • Continuous Prioritization
  • Continuous Learning and Improvement
  • Continuous Deployment

Continuous Feedback

  • Short feedback cycles. This is important on many levels, but the feedback from customer and user is the most essential.
  • Fail fast. If you’re heading the wrong way, don’t you want to find out as fast as possible?
    • In software development, it’s the rule,  not the exception, that you don’t know exactly what to make. This applies even to the smallest features.
  • Pair programming provides extremely fast feedback on a lower level and improves understanding and spread the knowledge among the team.
  • User feedback! Direct user feedback. Support organizations more often than not slows down the feedback.
    • Minimize the time from an error being introduced to that error being discovered and the person responsible is informed. (Fresh in memory, improves learning, prevents repeating the same or similar error)
    • Maximize the responsibility/accountability of the person who introduced the error. Hand-overs spread responsibility and prevent learning. Eliminate hand-overs!

Continuous Integration

  • CI is perhaps the one of these continuous processes that is the most widely adopted one. It’s become a de facto!
  • Test code with other databases, systems and code bases. Fail fast! Reduces risk and avoids merging-hell.
  • The more code to be merged or tested together, the more complex and time-consuming the integration task becomes. Performed in several smaller chunks, the same amount of code integrate much faster. It’s a non-linear relation, spread over many integrations, integrate faster overall than all in one. Nobody would dispute this? Thus, Continuous Integration reduces the overhead of having multiple developers and dependent systems.
  • Encourages TDD and good tests.
  • Continuous response is related, but are more focused on local level.
    • TDD. Run the test, get immediate feedback.
    • View. Immediate response from a code change to reviewing them on the screen. It’s a question of technology and product. Choose responsiveness!

Continuous Prioritization

  • Work by priority
    • The people in your project is incredibly valuable resources. Should we not play their best?
    • Is it at all rationally taken to defend anything other than that they will work with the highest priority tasks?
  • Continuous priority is about making decisions based on the best possible information base.
    • When we are best qualified to assess what is most important? Right now or in the planning phase of a year ago, a month ago or a week ago? Answers for themselves.
  • The priorities may (should?) change daily.
    • It reflects that you know and learn more as time passes.
    • Small changes are symptomatic of poor data collection, low feedback, wishful thinking or poor management.
  • KANBAN is most suitable for continuous prioritization as it’s a queuing system. Scrum is a more of a planning system, but with one week iterations it might be responsive enough? See my earlier blog post about KANBAN and Scrum combined, for more ideas.
  • Continuous prioritization is a task where one evaluates the business value against its cost. Both the business value and cost are variable in time and state of the project, for the very same feature or defect. A feature may have very low priority one day, only to get top priority a few weeks later.
  • Level of Detail in the priority depends on the actuality. You don’t detail tasks or user stories that won’t be solved in the near future. This is part of the thinking process you have to do, is it time to look more deeply into this feature set? Today, it might not be, but tomorrow or next week, it might be more important, within your larger plan or vision. (Plan, as in idea or concept, not in details with outdated and often incorrect assumptions)
  • Continuous prioritization is active management of the project!
    • what incentives are there to deliver the most business value, to cover most business needs, fastest, most often, to the customer? Fixed price represents the opposite, that’s in the nature of ‘fixed’. The only people who get a real opportunity to use continuous prioritization is where the customer is in control. If the customer doesn’t have people who have knowledge about running agile projects, there are alternatives, although seldom utilized in Norway, such as professional POs (Product Owner) etc. Hire an independent person who manages the project from the customer perspective, with contracted resources. The customer must have absolute power! All of todays contracts work against customers interests. If you disagree, enlighten me!
  • Continuous needs analysis is closely related to continuous prioritization, so I grouped it within it. Well, it is also closely linked to continuous feedback too. In fact, you might start to see that there is a greater connection among all these continuouses. Back to needs analysis:
    • Improve the decision base for continuous prioritization.
    • Active pursuit of potentially disastrous information. If you’re heading for a dead-end, wouldn’t you like to know as soon as possible? 10 resources on the wrong course for 10 weeks cost a lot of money! Worse, they have polluted the code base, which most likely will cost money during its entire life-time. Every line of code costs money after it is written. This is a fact.
    • Should the project be canceled? Split up? Actions like this is true management. I almost never see it.
  • How many projects actively seeks information and change their priorities accordingly?

Continuous learning and improvement

  • Try and fail, often and cheap!
  • Discard technologies, frameworks, products, etc. that do not meet the project needs, before they cost too much. Admittedly, I often make a bad choice, I bet that’s true for most of us. That’s not stupidity. Stupidity is when you see those choices through when you know better. Avoiding to seek information and learning is a real help to make people be stupid.
  • Continuous feedback has a lot to do with learning and improving as well. We’ve got the opportunity to learn from our choices. In the context of this blog post, learning and improvement are targeted at people, the individuals, not solely about the project and managing its direction. Each one of us should reflect and strive to become better!
  • Hold regular retrospectives, philosophize over the choices that were taken or not taken. Don’t forget the bigger picture, don’t delve to long in the details.
  • Refactoring, rewriting and other efforts to improve code quality, saves a lot of time. I know this is somehow counter-intuitive, but this is something most skilled developers know. Experienced, skilled developers are the ones that persistently deliver speed.
  • Continuous learning and improvement is the core of software craftsmanship. The IT industry evolves quickly, read and learn every day!
  • Standards
    • are good!
    • are not more than ideas that should change when you know better
    • should be challenged!
  • Did you learn a lot from the last software related book you read? How much time does it take to read one? How much time does the knowledge save you? How much time would the team save, given that you made the better choices?
  • Use 40% of the time to read, study and improve yourself. Use the rest of the time on the effective development and deliver better (more, faster) than  “100% of resources”. OMA’s postulate No. 1
  • Would you have done the last project in the same way again?
  • Would you have done the last feature in the same way again?
  • No will always be the answer to the two above, you know, after all, more now. But the answer to “how different?” will depend on how skilled you are.
  • Would you rather have a developer with 10 years of experience who are not interested in learning from others or to improve themselves, or have one with 3 years of experience, continually improving himself and actively seeking learning that often invalidates what he already have done or thought he knew?
  • “There is always something to complain about”, said a friend of mine. Yes, I guess so, but is it negative?
    • There is a huge difference in what Tiger Woods and a novice golfer complains about.
    • An élite player, even if he / she is world  champion, continues to focus on things to improve.
    • The novice will complain about the most basic things.
    • As you improve, you will find the next thing to improve, or “complain about”.
    • As an independent contractor, I find myself in projects and environments at very different levels. I’m surprised how huge the skill levels might be. I’ve noticed that at the places where the complaints are about the trivia stuff, such as “I don’t write tests before the end of the project”, the people are the least open to new ideas and lack the will to learn.
  • You can become unbelievably good, even being a father/mother with 8-16 job! It’s all about your attitude, but also a little about the attitude of your employer. You have to read some on your own spare time as well. If you’re not willing to invest in yourself, why should the employer be?

Continuous deployment

Continuous deployment. The one that binds all the continuouses together. It yields an extreme value increase! Strive for continuous deployment and you will automatically be paying more attention to all the continuouses mentioned above. They follow naturally! That’s worth a lot in itself. Other side effects will be

  • Release and deploy becomes a non-event. You’re simply getting good at it and automate the process.
  • Little code deployed often, results in:
    • fewer mistakes
    • fewer errors/defects
    • faster error fix
    • less code to search through to find the error
    • fewer critical error!
  • It is easier to fix errors in code you’ve just created and shipped, than in code you made days or weeks ago.
  • Frequent and fast deploy of AB tests. These are used to learn and improve your software choices based on statistical user feedback.
  • Incremental deploy is a good additional strategy. Roll out to 10% of your customers(or 10% of servers), deploying automatically to all the rest if it passes certain criteria (to detect memory leaks, major errors, etc).
  • If you have a defect, you know how to fix it, why not just do that and ship it right away? Really, why not?
  • Hand-overs will be proven as the money drain it is. It just doesn’t work! If you fix a bug on the hour, there’s no need to hand the code over to QA, testing, maintenance, operations or whoever. Follow the code through, making the developer responsible for it.
  • FLOW! Developers are more likely to find themselves in the flow zone (characterized as extremely effective and focused) when they create stuff that yield value (to the user) right away.
  • Momentum. How impressed will your users become when the bug they experienced gets fixed the very same day?
  • SAFE and SECURE. Perhaps the most difficult to comprehend. Most people today look at the deployment as a risky event. So the do it more seldom. This is stupid. See the very first bulletin in this section; deploy becomes a non-event.

Have you optimized the maintenance organization? Have you optimized management? Development og new features? Then you are sub-optimizing the whole. Please do not try continuous deployment in projects where the developers doesn’t have full control over everything. Don’t allow processes designed to prevent feedback, as a lot of support-organizations are (they said it nicer, “shield the developers”). Everything is connected! Understand what it takes, else you fail, brutally! The same is through for agile, it doesn’t work if you don’t understand the ideas behind it. I’m not looking forward to the time when the masses moves from agile or scrum, to KANBAN/continuous thinking, destroying it with their ignorance. Wow,  this section turned into a rant, please forgive me:) By the time this happens, I hope people have become better at asking the question why, putting my fear to shame.

Continuous Deployment is the future. This, I leave no doubt.  Flight technology, surgical instruments and other life-critical systems might be the exceptions. There are always exceptions.  You won’t let no life-support machine get online updates! Yet, we should realize that the big bang deploy are more risky than many small deploys. This should be taken into account with such “life-critical” systems as well, even if I’m not sure how. These were the exceptions. Your system is probably among the 99% of systems that are not among these exceptions. However, you’re probably facing significant organizational challenges, as 90% do. Unfortunately, most obstacles, as mentioned in my little rant in the previous paragraph, are mostly political and not technical. I plan to write more about this too, one day, but it’s risky business to rant too loudly. Some people are easily insulted and will give my lots of good titles and names… Continuous Deployment for the win!


There are lots of good techniques from XP, agile and lean. The continuous processes reinforce them, which in itself is worth a lot. Continuous Processes show clearly that hand-overs reduce delivery capability, so developers rather follow the code through to production, facing all the challenges and consequences of their own choices. Thus,they learn stuff they never knew they didn’t know, advancing to write better code with less defects. Get started with Continuous Deployment and tell me all about it! I’d like to learn and I’d like to invest!

Some related links:


About Ole Morten Amundsen

Developer, programmer, entrepreneur. Java, .Net, ruby, rails, agile, lean. Opinionated enthusiast!
This entry was posted in agile, Java, lean, methodology, rails, ruby and tagged , , , , , , , , , , . Bookmark the permalink.

One Response to The Continuouses

  1. Pingback: Amusant comme l’agilité change tout… « Jidup's Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s