Resume for Steven E. Newton
Readings for Code Janitors
Steven E. Newton
Crater Moon Development
There are few programmers unfamiliar with Fred Brooks’ eponymous law. Those with experience in more than a couple of projects will have seen deadlines missed, and witnessed the nearly inevitable response from management. Few managers are able to resist the siren call of throwing more bodies at the problem.
To my mind, a more important contribution from Brooks is his analysis of the complexities in software development.
The essential complexities in software are in the problem space itself. This kind of complexity cannot be reduced without changing the problem being addressed. Calculating spacecraft trajectories, predicting the weather three days from now, creating cryptographically strong encryption. Those are complex problems.
The other kind of complexity is a byproduct of the way we’ve designed something, with choices we’ve made. It is the complexity introduced in trying to solve a problem. It’s possible to reduce accidental complexity by changing the design, tools, or process in our software.
In nearly every project of any size I’ve been involved in, there’s at least one programmer who introduced at least one unnecessarily complex attempt at a solution.
It might be the young hotshot who recently discovered Java anonymous inner classes and closures and sprinkles them everywhere. Clever. Too clever for most of his colleagues, leaving a mass of code only he can understand.
It might be the mid-career programmer whose infatuation with functional programming styles leads him to shoehorn an entire obscure library of functional constructs into Java. Functional programming is amazing, with the right tools. The awkward twisting of a language designed for one paradigm into a language for a different paradigm is not.
It might be the engineering manager who hires a bunch of his friends from a previous job and gives them free reign to “do things the right way”, despite having no relevant experience in the business domain. Then his team goes 18 months with 3 new products started and none released to production.
These are self-owns. None of the complexity was inherent in the problems being solved. The attempted approaches introduced both short- and long-term consequences. Progress and ultimately success were hampered by overlooking simple solutions.
I firmly believe the emergent behavior of software is one of its key properties. Complex behaviors arise from simple rules, and software development doesn’t require complex implementations. Emergent behavior is inevitable.
This emergent behavior is a key issue in dealing with a system of any real size, because it’s almost certain some properties have emerged, as a result of the interactions, to become expected or even desired behavior of the system. The greater the complexity, the harder it is to know if or when a change will affect those desired emergent properties.
Perhaps the simpler we keep the implementation, the more emergent behavior software will express. What Eric Evans calls “supple design” in Domain-Driven Design helps manage the interactions. Simple rules are easier to reason about. They are easier to change and recombine in different ways.
Brooks noted the how the use of simplifying tools and languages led to improvements in software development by reducing accidental complexity. While he might be more famous for noting wryly, “The bearing of a child takes 9 months no matter how many women are assigned”, understanding the reason why adding people to a late project makes it later provides deeper insights into the difficulties of software development.<-Deep Into Technical Debt Code Janitor ->