Adam Jordens

Canadian @Netflix'er. I've had a few failed startup projects over the years but keep coming back for more.

© 2017. All rights reserved.

Moved to Medium

02 Mar 2017

As of 2017 this blog has moved to Medium.

Code Ownership vs. Technical Debt

14 Apr 2013

Lately I’ve been thinking about technical debt and how it’s accumulated over the course of a company. 

Thinking back upon many a software project, it’s becoming clear that a lack of decisive ownership can be a significant contributor to technical debt and frustration amongst teams.

Ownership goes far beyond just writing a design doc, or doing the odd code review. It’s holding oneself accountable for everything that happens within a codebase, from now until such time that it’s been handed off to someone else (who equally understands the role and responsibilities). 

You’re expected to work with contributors, maintain the quality bar, resist unnecessary complexity or features (the inevitable “we don’t know where else to put this feature, lets put it in this artifact”), and otherwise keep things moving forward. There’s nothing to say that ownership can be spread across a team, but everyone needs to be on the same page. 

If what I’ve described sounds like an open-source project, that’s by intention. I think there’s a lot that can be borrowed from successful open-source projects and applied within corporate environments. 

Over time, codebases without ownership have a tendency to be labeled as “legacy”. In the open-source world, they would likely be abandoned but in corporate america, they almost always live on. The valiant few will jump right in and try to affect change within, but more often than not, these efforts merely chip away at the surface leaving systemic issues below. To the business, this is working and (hopefully) revenue generating code. For most teams, there is little patience or motivation for maintenance when far more exciting nuts to crack are looming on the horizon. Unfortunately, there is almost always something more important than investing in your existing code.

Every so often, things get bad enough that an organization might attempt wide-scale refactoring or perhaps even small (or large)-scale rewrites. 

A cautionary tale. If you’re going to refactor your codebase, don’t just shuffle bits around. Refactor it such that you can assign ownership amongst pieces with very clear delineation. 

The Perfect Agile/Scrum Standup Redux

09 Feb 2013

It’s been two years since Daniel Markham shared his thoughts on the daily standup.

One of the good things about successful software development approaches, is that what worked 7 or 8 years ago is still applicable today, despite significant changes in technologies, platforms and work environments. The How may be different now, but the What and Why remain the same.

Case in point, over nine years ago I joined a little startup building life sciences software in a small west coast Canadian city. The team was small, young and definitely inexperienced in the ways of professional software development. But we figured it out, through trial and error our team processes and daily stand ups got progressively better.

The team wasn’t afraid to suggest improvements and point out flaws when things didn’t go well. The key to successful agile/scrum/anything is absolutely having a passionate team. If you can get the right people on the bus and keep them there, you’ll do alright regardless of process. 

Fast forward to today, and the development processes we’re using now are simply a refined version of what worked in years past.


The Daily Stand-up

It’s interesting to note that although our intuition can probably tell us what makes for an effective stand-up go well, we often don’t act it. For example, it takes only one question / side-discussion mid stand-up to de-rail the entire process. Daniel called for decision making to occur after the stand-up and I’ve certainly been a culprit of this. For any team member with a vested interest, it’s all too natural to immediately chime in and attempt to problem solve or dig deeper. Avoid doing this.

It’s important to recognize and call-out the end of a stand-up. Even a simple, “and that’s the stand-up“, suffices. It provides an opportunity for those with nothing further to add to get back to their work, and anyone with a deeper topic to stick around. Truth be told, discussing every question, issue or story as a team can be disrupting and exhausting. 

There is a certain amount of learning that a team needs to go through in order to get better. Regular reflections are important. I’ve been in situations where certified scrum masters, project managers, etc. have been brought in to fulfill a perceived gap. With almost certainty this idea of parachuting in a hired gun never worked and led to added frustration amongst the team. It’s not until the team has convinced themselves that there is a gap or unresolvable deficiency that change became reasonable.

I agree with Daniel that the stand-up should avoid divulging into a status report. It’s important to gather around something physical, like a whiteboard, that outlines the current state of the sprint or iteration. There are digital tools (Atlasssian Jira, etc.) that replicate certain aspects of this, but nothing replaces physically moving story and task cards in front of the team. When using both digital and physical tools, please make sure that they are kept in-sync.


If there’s one piece of information to share during your standup, it’s when your current task is expected to complete. That style of update can give a better indication of progress, as opposed to simply iterating what has been completed so far, or all the minutia that remains. It also provides fodder for your team lead / product owner and anyone else that is counting on your deliverables, including your QA engineers.

Quick Tip: Aim to keep your tasks and stories small (< 3 days), it’s far easier to mentally track and report progress. 


Go back and read Daniel’s post again, and follow me on Twitter.