Being a Code Custodian

The roles of a team lead can vary dramatically depending on the team dynamics. Being a code custodian may or may not be appropriate for your organization. I have found it valuable in some situations. There are automated and manual approaches to monitoring the integrity of software. I like to apply both when appropriate. Each has pros and cons:

• Automated Approach - Usage of software tools to detect potential defects and/or style violations
• Advantages
• Can check for a large number of potential defects and/or design smells
• No ongoing time investment after initial investment to setup and configure
• Can be tied into CI environments like Jenkins to guarantee adherance
• Disadvantages
• Not good at catching the most important issues
• If rules are configured too restrictively, becomes more of a hindrance than a benefit
• Manual Approach - Human review of checkins or some subset of checkins
• Advantages
• Only way to catch many types of issues
• Keeps the reviewer abreast of new development
• Leads to mentoring opportunities for the reviewer
• Good way for the reviewer to learn from other approaches and pickup new techniques
• Disadvantages
• Difficult and important to be completely objective and remove opinion from feedback
• If applied heavy-handedly 
• Kills developer empowerment
• Can be disastrous to morale
• Time-intensive
• Spotty
• Usually unrealistic to fully check everything

I would further decompose automated approaches into 2 categories.

• Category 1: Surface Analysis - Static-analysis tools including lint, checkstyle, and findbugs
• Advantages
• Customizable
• Rules-based
• File-driven
• Easily integrated into many modern IDE's
• Easily integrated into build or CI environments via a CLI
• Many free or open-source
• Often mature and robust
• Disadvantage
• While they can catch many "surface" issues, they don't always dig very deeply
• Category 2: Deep Analysis - Tools that looks more deeply into aspects such as cyclomatic complexity, memory usage, and performance. 
• Advantage
• Tend to be higher value 
• Disadvantages
• Difficult to automate
• Some intended more as an aid for manual test and debug
• Some produce results that should be inspected and interpreted
• Can be difficult or impossible to quantify rules for
• Less typically free or open-source

In the next two posts I will delve into how I applied these tools in recent projects.

Design and Architecture in an Agile Environment

I have worked in several "scrum-like" agile environments over the years. I say scrum-like because each adopted some of the principles, but was unable to embrace all. In almost every case the biggest casualty tended to be an inability to totally isolate the development team from shifting priorities in the middle of a scrum. This is a difficult problem to address, particularly when working with exceptionally demanding customers, and perhaps a topic for another day. Another possible discussion item is whether or not "partial-scrum" is scrum at all.

One of the industry trends with agile environments is to tradeoff up-front design and architecture for an "emergent design" iterative environment where coding starts immediately. However, I would argue that agile does not, and should not, imply that there is no up-front design. Iterative development does not mean that you should rewrite the entire system in every iteration. Nor could anyone reasonably argue that this is an efficient use of the team's time. Yet, if you jump into implementation without any design the chances of "coding into a corner" greatly increases, potentially producing exactly this type of situation.

So we shouldn't give up design and up-front thought any more than we should give up good coding standards. Fast development does not have to equal reckless development. A technique I have used in some organizations is to have one or two senior developers/architects sign up for design and architectural tasks as deliverables for the sprint. These deliverables can be tracked much like any other deliverable, and are as integral to the sprint's success as code and QA deliverables. The end-result should be a light design in some electronic format, with buyin from the team and stakeholders.

The only real disconnect with the scrum process of adopting this technique is that typically the one-or-two people working on this task have a different focus from the rest of the team. This work is synergistic, however, as it results in a better definition of development backlog tasks for subsequent sprints. From this perspective, the team performing these tasks could be their own scrum, but often this is not practical because of how small the team is (could be one member) and because the members will often also take other tasks from the ongoing development sprint.

Another approach that I have seen work is to break up chains of sprints with planned one-or-two week intervals for the team to do design and architecture of  backlog items and cleanup work from prior sprints as needed. Whether this work is considered a sprint or not is up to the team, but I have found that occasional "unstructured" time is also useful for a team.

"Does design and architecture play a role in scrum? If so, what techniques have you seen work and which have you seen not work?"

Balancing Performance with Code Readability : Case Study (Android, Java)

Google has a number of blog posts on how to write code for Android performance. They make recommendations that conflict with normal Java standards such as avoiding enumerated types and using counter-type  loops over their collection types. They make good arguments for comparative performance improvements for each, but I think it's good to step back and evaluate Google's motivations before blindly applying all their recommendations.

• Motivation 1: Bad apps make Android look bad
  
  From Google's perspective, a few misbehaving apps can make the entire ecosystem look bad when compared to the highly controlled ecosystem of Apple. This is especially true for apps that are bad citizens (e.g.- consume more resources than needed for longer than needed, services that run longer than needed, activation of power-hungry resources like GPS hardware for longer than needed). Other recommendations are performance-oriented. There is little motivation for them to recommend well-written code over code that grabs every nanosecond of performance. They aren't the ones supporting the apps, after all.

• Motivation 2: Wide range of hardware capabilities
  
  Often times developers will test only on a high-speed device over WiFi or 4G and not understand the implications of how their app will run on older or less expensive hardware or over slow Edge networks in China or elsewhere. With the advent of smart devices like watches, the limitations can be even more severe, especially for  battery life.

While I strongly endorse writing programs that are good citizens, other recommendations to grab every nanosecond of performance I often find as not always necessary. I also have the luxury of architecting, designing, and developing apps for specific high-end Android devices, which makes motivation 2 less relevant. Even if this were not the case, I still prefer to write first for readability and, only when proven necessary, refactor for performance.

An example of where I recently found this  useful was in creating code whose function is coordinating an external set of contacts with the Android native contact database. There were a number of fields that were to be synchronized and the list of exactly which would be synchronized was subject to change. I found code in another application that someone wrote to do something similar as a reference. The author of this code created a string projection  where each ordinal was referenced by number into that projection. Insertions or deletions of values in this projection would change the meaning of each ordinal, making the code very brittle.

I introduced an enumerated type for storing the elements of the Android database string projection and relied on the ordinal position for later retrieving columns from this projection. The structure was thus "self-aligned" making for easy removal and addition of elements to the projection. The enum looked something like this:

Access to the columns, could then use the ordinal of the enumerated values like so:

instead of using "magic numbers" which rely on the order of the elements in the projection (in this case it would have been "1").

The new self-aligned approach is both much more readable and less susceptible to bugs as the code changes and there was no noticeable performance hit.