Roadmap to Lean-Agile Programming Competencies

Note: Most of the links on this page require registration for access to them.

Professionalism

What is a profession, is what we do a profession, and why would we care?

In all complex human endeavors, there is value in capturing those aspects of our efforts which have been proven to be universally true. In medicine, for example, it was not initially considered particularly important to wash one’s hands and instruments; once this was proven, and accepted by the overall community of doctors, the entire field became fundamentally more successful.

Professions are, among other things, entities that can capture these universal truths to pass them on to future generations, and to ensure that everyone participating in the overall effort understands and adheres to them (The surgical operation does not go well if only some of the doctors and nurses involved believe in germs). We are ever-increasingly vulnerable to the quality of the work of other developers and development teams.

Whether you prefer to think of what you do as a profession, a craft, an art, a science, or some other term, there is value in knowing what these universals are, and also what basic skills every developer should have. This can help to improve your value to your organization, certainly, but also can increase your own sense of confidence and self-worth.

Also, many of the aspects we list below are synergistic. That is, learning about one of them will help you to understand others, or to deepen your understanding of them all.

Of course, we cannot claim to have found everything that belongs on this list. This is what we know now, and will serve as a good starting point in trying to create this kind of shared universal knowledge. As we learn more, we will add to it. If you think something is missing, we’d love to hear from you.

People learn in different ways. For some of you, the list below will, in and of itself, be useful. For others, the resources each concept links to will prove to be a valuable investigation of some depth. For yet others, reading a comprehensive book or coming to an intensive course will be the best way to learn. For most of you, it will be some mixture of all of these things.

At Net Objectives we hope to serve you all.

Code Qualities

What is “good code”? It depends on what you want from it. In the beginning of the software development profession, computers were extremely slow and expensive, and developer time was considered to be a less-critical commodity. Not surprisingly, we did whatever we could to make things easy for the computer to do, even if it made the system very hard for the human developer to work with.

This dynamic has fundamentally changed. Computers are fast, cheap, and software is therefore pretty much everywhere. Developer time is the primarily expense of most development organizations. “Good Code” today, generally, is code that requires less developer time to change, reduces the risk of change, and which will help the system to maintain its ROI for as long as possible.

These are qualities of code that make for more flexible, maintainable and extensible code:

Coupling
Cohesion
Encapsulation
Focus
Readability
Redundancy
Testability

Principles

Knowing the qualities that define the nature of the code that you seek is useful, but we also need to know the underlying principles that will, most reliably, lead us to those qualities. Also, principles will help to keep us aligned with qualities when unusual, unforeseen, and unfamiliar problems arise. Principles are general guidance about creating good software; there is no “end” to following a principle, you could always “do more”… but in following them generally we find that everything gets incrementally easier to change, scale, and extend.

These are principles that should be followed when creating software.

Encapsulate by Policy, Reveal by Need
Open-Closed
Separate Use From Construction
Shalloway’s Law and Shalloway’s Principle
Single Responsibility

Practices

A practice is something we, as a community, have discovered is simply always a good thing to do. For something to be promoted as a practice, it must be truly universal (you can always do it, and everyone should do it). Therefore, it must be:

  1. Easy to do. We don’t want to burden ourselves or slow ourselves down because of a practice.
  2. Easy to teach. If we want everyone to do them, it should not be a burden to propagate their use across the entire team, organization, and the profession itself.
  3. Be highly valuable. A good practice should pay you back over and over and over again.

Returning to the medical analogy, all doctors wash their hands before dealing with their patients. It is not hard to do, it’s easy to teach others to do, and it has made the entire profession fundamentally more successful.

These are practices that meet all three of these standards:

Programming by Intention
Make State Private
Encapsulate Constructors
Perform Commonality-Variability Analysis

Wisdom

Our profession is a young one, especially compared to others like the Law, Medicine, and so forth. However, we have enough history now to be able to draw upon the experience and wisdom of our senior members, those “grey hairs” who have encountered and analyzed many of the issues that confront us. Where we can, we should draw upon this wisdom, and then build upon it for those who follow us.

These are the elements of wisdom we believe every developer should understand:
From the GoF:
Design to Interfaces
Favor Aggregation over Inheritance
Encapsulate Variation
From Fowler:
Separate Perspectives of Concept, Specification, and Implementation
From Coplien:
Use Abstractions to create longevity in your designs and architecture
From Alexander:
Favor Design by Differentiation over Design by Synthesis

Patterns

Wisdom applies generally, as principles do, but also in specifics ways when confronted by specific kinds of problems. When these specifics repeat, there is value in sharing the patterns that we discover, giving them names to make them more shareable, and thereby creating a professional vocabulary.

In our profession there are many books on patterns. Trying to “learn all the patterns” is probably too much to ask, and also is not really necessary once we understand the principles, practices, and wisdom that underlie all patterns.

There are patterns that seem to arise in all domains, and that represent the best examples of the general value of pattern. We consider these to be those essential patterns, those that every developer should know, listed in the order we suggest you learn them:

Strategy
Template Method
Bridge
Adapter
Facade
Analysis Matrix
Abstract Factory
Factory Method
Iterator
Singleton
Proxy
Decorator
Chain of Responsibility
Composite
Object Pool
Mediator
Observer
State

There are other patterns which can be useful to know, and which can deepen the understanding a developer has of the value and nature of patterns overall. Once the list above is mastered, we suggest the following are good patterns to focus on:

Visitor
Flyweight
Builder

Discipline

This list, taken overall, constitutes a Discipline, a shared set of distinctions that drive decisions and actions overall. At Net Objectives we call this discipline “Pattern-Oriented Development” because we use patterns to drive the overall process, not just to solve individual problems in implementation.

This is only one discipline, however. There is another, which we also believe all developers should know of, understand, and practice. This is the discipline of “Test-Driven Development”. The underlying qualities and principles are the same, but TDD “gets you there” in a different way. Also, there are specific patterns and practices in TDD that enable the process (refactoring, automated testing, mock objects, dependency injection, etc…)

Click here for our courses in TDD.