Retrospectives, Tech in the 603, The Granite State Hacker

Context is for Kings

A retrospective in software development methodology is a look back at a project cycle. Usually, a retrospective refers to a formal meeting held at the end of a development cycle. Retrospectives provide context for where you are, and can help you figure out where course adjustments might be needed.

I’m going to start a series of project retrospective blog posts. My intent is to go a bit beyond the standard “lessons learned” aspect of a classic case study by discussing ways to address those lessons learned if I were delivering on the same requirements today.

I understand there’s some risk in this. The very nature of talking about “what I’d do different today” is a dynamic target. The answer could be different tomorrow, when you’re reading this. Perhaps that’ll be another chance to revisit the topic.

In these posts, I’m going to go over my own project history and do a full post-mortem on whole project deliveries. In order to protect potential client property, I’ll generally avoid identifying the client I did the work for and/or any publicly known project name. Teammates familiar with the projects will be able to identify them, but that’s ok.

Whenever working on a longer-term, non-trivial application, it’s inevitable that before the project is completed, technical debt sets in. Most commonly, some of the components are obsoleted by newer versions of tools used in the project, and there’s no immediate need or budget to update it. As long as those tools are still supported, it’s generally de-prioritized as a problem for another day. Longer term, everything is eventually obsoleted.

Another inevitable part of code development is the classic “if I had it to do over again” aspect. This is a big-picture extension on the old “Make it work, make it right, make it fast” practice. The first time through a project, there’s always “make it work” moves that end up being what gets delivered, without opportunity to get to the “make it right” / “make it fast” cycles. If I had the project to do over again, I’d “make it more right” or “make it faster” by doing ‘X’.

Likewise, every project cycle has its ups and downs in terms of team interaction. Some times folks are on the ball, and the code flows. Other times, there’s what we call blockers… things that hold up progress.

A blocker could be any number of things.

A common blocker is missing or incomplete requirements. It’s hard for a programmer to teach a computer to do work if the programmer doesn’t know how to do that work.

Another common blocker is access or permissions. A programmer might have a requirement to develop code that depends on another service. If that’s the case, the programmer might be able to build an abstraction of that service, but eventually will need permission to access that service in some form to do integration testing.

In this case, I’ll still take the classic retrospective approach. I’ll address the following questions:

  • What did we set out to do?
  • How and why did we deviate from plan?
    • What worked?
    • What didn’t work?
  • What would we like to do next time?
    • How could we improve what worked?
    • How will we minimize the risks of what didn’t work?
    • How will we address any technical debt incurred?

Some retrospectives avoid management in order to avoid addressing these questions politically. In better situations, some representative of management and/or project stakeholders are included in order to get a more complete view of the project.

In my posts on the topic, it’ll just be my perspective, and I’ll be addressing the questions holistically. Having completed the projects and disbanded the delivery teams, with minor name changing to protect the innocent, politics need no longer apply.

I’ll admit, there’s some self-gratification in doing these post-mortems publicly. I’ll be able to show off experience, and hopefully grab the attention of folks who’d like to produce similar projects. My hope is to inspire more of the latter and spark up the conversation around how to apply similar solutions (preferably with the “desired state” improvements).

Tech in the 603, The Granite State Hacker

Looking into Continuous Delivery / Lean Enterprise

After a conversation with my boss I just downloaded Continuous Delivery to my Kindle reader (Windows 8 / Windows Phone app). 

On first brush, I can see it’s akin to the next phase of a process I’m somewhat familiar with.  I’ve referred to it as Software Factory in the past, and even have a label for it in this blog.  I designed and delivered a “Software Factory” solution around some of these concepts at one of the few product based companies I worked at in my career…  

“Software Factory” took Continuous Integration (CI) up a  few notches by automating not just builds, but code generation, deployment packaging, and then an early stab at what might now be called a private cloud, where we automated spinning up an instance of target test systems, deployed the fresh baked product, ran smoke tests, and (if smoke tests looked good) notified the folks in QA for more complete testing of a solid candidate.   


I’ve been a fan of Domain Specific Language (DSL) for the purpose of custom build & automation ever since. 

For that company our solution was an on-premises deployment, so it was still a matter of convincing customers to deploy the updates…  but our automation produced both full install kits as well as patches that would upgrade a running system from a known build to a target build.    


That company was preparing to take the product into the SaaS model which was very new at the time, and this would have been a part of that, as well.   

I’ve worked with TFS to integrate smoke testing and build automation, as well.  That could easily extend to this sort of thing. 

That company suffered from lack of customers, unfortunately, but it was a process I’ve been looking forward to getting back to, and expected we’d get back to in the consulting world some day.    It’s interesting that Software Factory (as Continuous Delivery) is working it’s way back to top of mind relevance through the cloud…  I’m looking forward to reading what the authors of this book have to say about it.