clarity

Do lines of code matter…

/ Isaac Hogue / 1 Comment

messy vs clean

Recently while having a discussion about how to keep code clean,  the person with whom I was talking stated “if we were to manage our code that way our lines of code would be huge…” or something to that effect  🙂

I agree that lines of code can make an impact on the overall health and sustainability of the code; however, here a few things that I would offer up that matter more than the number of lines of code:

  1. The code’s focus – how many problems is the code attempting to solve
  2. The code’s simplicity – how cleaver is the code, does is it do exactly what you think it will do if you were to only read the names of it’s various parts,
  3. The code’s testability – how easy is the code to verify when changes are necessary,
  4. The code’s coupling – how many other areas of code will need to be tested if I were to change the code, and
  5. The code’s resiliency – how impacted will this code be when other code changes

My suspicion is that the individual that I was talking with had encountered some crazy code that was hard to maintain, hard to triage, hard to test, brittle, and hard to understand over the course of their time working in code.

Generally, code like this is also huge; but, if an overall solution’s line count is huge and the individual pieces of code are focused, simple to read, highly testable, loosely coupled and resilient to change, the size of the overall solution will matter much less.

That’s my take, let me know what you think.

Advertisement

The next most important thing…

/ Isaac Hogue / Leave a comment

do this next

Finding your next most important thing is critical and requires clarity.  As teams begin thinking about how to address their meetings, the topic of a previous post, its critical that they first identify where the team needs to focus its energy over the next 1-3 months, or the “Next most important thing” the team needs to do in order to succeed.

So, how would a team go about identifying their “next most important thing”… It’s a fairly straightforward process.

For the sake of a tangible example, I’d like to use a set of three types of teams that I work with on a regular basis, teams that operate within a three tier enterprise product development structure.  These teams and their purpose would be defined as follows:

  • Product development team: Produce the next most important working increment of product within a couple of weeks.
  • Program team: Establish and provide clarity for and to product development teams about the next most important increments of product that are needed within the next few months.
  • Enterprise portfolio team: Establish and provide clarity for and to program teams about their next most important thing for the portfolio to succeed.  This usually requires creating or maintaining a multi-quarter capacity-aligned roadmap for the products and services that are owned by the portfolio

With these perspectives in mind here is the process that I would recommend for identifying the next most important thing within each team:

  1. Review the team’s primary purpose,
  2. Ask each team member to write down the one thing within its control that is keeping the team from fulfilling its primary purpose,
  3. Review the team’s suggestions and filter the list down to the one thing that the team agrees is the most important goal for the next period.

its important to recall that the next most important thing for a portfolio team may look very different from the next most important thing for a product development team.

So, how would a portfolio team member identify the portfolio’s next most important thing? I’d recommend that they answer this question:

What is keeping our portfolio from delivering the next most important increments of product into the markets within the next 3-9 months?

Likewise for a program team member I would recommend the following question:

What is keeping our program from providing clarity to the product development teams about the next most important increment of product?

And finally for a product development team I would recommend the following question be answered:

What is keeping our team from delivering a working increment of product within a couple of weeks?

In each of these cases, the next most important thing would be directly tied back to the primary purpose for the team and would be expected to be resolved within a short period.  Once we know what the next most important thing for the team is, we can start to identify which types of meetings we will need and how frequently we will need them to ensure that we are accomplishing our next most important thing.

What do you think, are there other examples that you would like to hear more about or perhaps where you have seen this fail?

And as always, thanks for reading and sharing your feedback!