In The Wrong Abstraction, Sandi Metz says the cost of code duplication is less than the cost of using the wrong abstraction. I had to watch her Rails 2014 talk to fully understand her point. She discusses the cost of duplication around the 13:58 mark.
I watched the entire talk. The ideas are presented so well that it's simply brilliant.
The main take-away with respect to the cost of code duplication verse the wrong abstraction is that it's also an argument for delaying the application of DRY until you fully understand the algorithm.
What makes her presentation compelling is the insight she provides on knowing when to apply DRY. It's the first time I've seen someone provide a practical example of why delaying the application of this principle is important.
In addition to the insight provided on applying DRY the talk contains a great deal of practical advice.
The presentation provides a useful tool for explaining the evolution of code through the ebb and flow of complexity during development. The presentation is directed at individuals attempting a refactor. The Wrong Abstraction includes the notion of a team working on the code.
I plan on using the presentation as a vehicle to help my team understand the challenges they are facing in their own struggles with complexity. Having the tools to discuss this challenge goes a long way towards understanding and finding solutions to it.
The Wrong Abstraction introduces the notion of the sunk cost associated with using the wrong abstraction and makes an argument that developers need to recognize this accept that sometimes the best way out of that challenge is to take a back step by reintroducing duplication. It is the step back which provides the opportunity to revisit the abstraction and improve it.
March 25, 2017
Practical Application of DRY
—A look at how to properly employ the "Don't Repeat Yourself" principle.
March 19, 2017
It's The Foundation That Matters
—Understanding the fundamentals are critical to staying relevant.
I have to agree with Santiago L. Valdarrama and the points he makes in The unremarkable career of (some) modern software developers. Continuously learning is important to your career. Complacency is a career killer.
I've resigned from two positions during my career because those organizations got in the way of my learning or didn't provide the opportunity to apply it. Staying in these organizations comes at great personal cost. It's a cost that can sneak up on you if you aren't vigilant.
In addition to building a solid foundation build a broad network to get better insight on the issues you face. I discuss some of the pitfalls of social proof and social loafing in Stop Being a Cave Dweller. These pitfalls are an issue if you think Google and Stack Overflow are your friends. (They certainly help but you need to think as well.)
The response on Reddit to Santiago's blog post is interesting. In my view Santiago's, point is understand the theory and stay sharp. The fact of the matter is that technology changes. You need something to carry with you as you move through your career. That something is probably a solid foundation in fundamentals that can carry you for the long haul.
I've resigned from two positions during my career because those organizations got in the way of my learning or didn't provide the opportunity to apply it. Staying in these organizations comes at great personal cost. It's a cost that can sneak up on you if you aren't vigilant.
In addition to building a solid foundation build a broad network to get better insight on the issues you face. I discuss some of the pitfalls of social proof and social loafing in Stop Being a Cave Dweller. These pitfalls are an issue if you think Google and Stack Overflow are your friends. (They certainly help but you need to think as well.)
The response on Reddit to Santiago's blog post is interesting. In my view Santiago's, point is understand the theory and stay sharp. The fact of the matter is that technology changes. You need something to carry with you as you move through your career. That something is probably a solid foundation in fundamentals that can carry you for the long haul.
February 24, 2017
Engineering Logs for the Product Backlog
—A look at managing technical debt.
I'm experimenting with how to better control and pay down technical debt. The objective of this experiment is to determine if we can align the payment of technical debt with asks from business stakeholders.
Martin Fowler says this about technical debt:
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
The tricky thing about technical debt, of course, is that unlike money it's impossible to measure effectively. The interest payments hurt a team's productivity, but since we CannotMeasureProductivity, we can't really see the true effect of our technical debt.
The balance between the quick and dirty solution and the deadline is critical here.
I include in quick and dirty, those outcomes which aren't as successful as we had hoped--those situations were once you complete the implementation you realize how to create a simpler implementation but you are simply out of time.
To improve balance, I use an engineering log to identify potential improvements and align those improvement with requests by the business.
An engineering log is a list of things we need to do to improve the product but which are not going to add to the value the business can extract from the market--refactoring code falls into this category. Importantly, my engineering log is not in my Product Backlog.
The basic idea is that a refactor usually needs to proceed the introduction of new functionality. This is likely true if you are working on a legacy code base. In my view, this refactor is limited to the work needed to make the introduction of the new feature easy.
I use the engineering log to identify technical debt and include the payment of that technical debt in stories motivated by the business.
This has the advantage of aligning the repayment of technical debt with a business objective, so code that's "good enough" isn't refactored until there is a new business requirement for that code. It has the disadvantage of adding cost to the business activity.
The disadvantage does have a business impact. I don't have a solution for that other than to write the code right the first time.
February 18, 2017
The Accidental Creative (Stimulating Creativity)
—A book review on Todd Henry's Die Empty.
Several years ago I read The Accidental Creative. I shared my thoughts on the book in The Accidental Creative (Book Review). I've also read Die Empty. Both are recommended reads.
The Accidental Creative includes a framework to ensure you remain creative over the long term. One part of this framework is to ensure that you "Curate stimuli that help you pursue creative possibilities." I've found that an effective way for me to remain creative is to review writing that I've enjoyed either because it's entertaining or because it's thought provoking.
Recently, I've begun to ensure that I select one piece of writing to read each week. This is always something that I've read in the past and I take the opportunity to revisit part of it over the course of a weekend. The result of randomly selecting a piece of writing that has influenced me in some way is profound. I find that I reconnect with some of the ideas that have inspired me and that I can make new connections on how to solve current problems.
Food for thought.
Die Empty: Unleash Your Best Work Every Day by Todd Henry
My rating: 5 of 5 stars
View all my reviews
The Accidental Creative includes a framework to ensure you remain creative over the long term. One part of this framework is to ensure that you "Curate stimuli that help you pursue creative possibilities." I've found that an effective way for me to remain creative is to review writing that I've enjoyed either because it's entertaining or because it's thought provoking.
Recently, I've begun to ensure that I select one piece of writing to read each week. This is always something that I've read in the past and I take the opportunity to revisit part of it over the course of a weekend. The result of randomly selecting a piece of writing that has influenced me in some way is profound. I find that I reconnect with some of the ideas that have inspired me and that I can make new connections on how to solve current problems.
Food for thought.
Die Empty: Unleash Your Best Work Every Day by Todd HenryMy rating: 5 of 5 stars
View all my reviews
January 26, 2017
RBTLIB's Whole-Part Hierarchy
—A look at implementing a client-side library for Review Board.
In RBTLIB - A Client-Side Library for Review Board I introduced an implementation of a client-side library for Review Board. In that post, I described the next steps for the library including the introduction of the composite pattern to manage the whole-part hierarchy defining a resource.
The implementation includes the composite pattern implemented using named tuples. I chose named tuples because I wanted to avoid an implementation that makes explicit use of meta-classes (named tuples use meta-classes).
I wanted to avoid meta-classes because of my goal for a simple implementation. My notion of simple embodies the notion that the code be straight-forward to read and understand. I find decorators to be a simpler alternative to meta-classes. The "hard part" of using decorators is that the implementation requires decorator chains.
I introduced a JSON attribute to each top-level named tuple. The resulting implementation includes two copies of the resource definition: the JSON attribute containing a copy of the Review Board response and a whole-part hierarchy for each resource component.
The introduction of the JSON attribute is an experiment. I am still not sure what I want from my client application. The applications defined in the scripts still return the JSON structure provided by Review Board. My current rationale for doing this is that I like the notion of using these scripts to support the plumbing and porcelain notion used in git.
For example, an implementation of RB Tools using RBTLIB might rely upon the scripts instead of the RBTLIB API directly. The plumbing and porcelain notion in git works very well and I think the separation of the two might create the opportunity to easily extend RBTLIB or the RB Tools clone very easily.
RBTLIB supports only retrieval of the Root and Review Request resources via HTTP GET. A good test of the design needs to include support for the remaining resources and support for HTTP POST. HTTP POST may take the design in an entirely new direction so there may be compelling reasons to support HTTP POST before introducing the remaining resources.
The implementation includes the composite pattern implemented using named tuples. I chose named tuples because I wanted to avoid an implementation that makes explicit use of meta-classes (named tuples use meta-classes).
I wanted to avoid meta-classes because of my goal for a simple implementation. My notion of simple embodies the notion that the code be straight-forward to read and understand. I find decorators to be a simpler alternative to meta-classes. The "hard part" of using decorators is that the implementation requires decorator chains.
I introduced a JSON attribute to each top-level named tuple. The resulting implementation includes two copies of the resource definition: the JSON attribute containing a copy of the Review Board response and a whole-part hierarchy for each resource component.
The introduction of the JSON attribute is an experiment. I am still not sure what I want from my client application. The applications defined in the scripts still return the JSON structure provided by Review Board. My current rationale for doing this is that I like the notion of using these scripts to support the plumbing and porcelain notion used in git.
For example, an implementation of RB Tools using RBTLIB might rely upon the scripts instead of the RBTLIB API directly. The plumbing and porcelain notion in git works very well and I think the separation of the two might create the opportunity to easily extend RBTLIB or the RB Tools clone very easily.
RBTLIB supports only retrieval of the Root and Review Request resources via HTTP GET. A good test of the design needs to include support for the remaining resources and support for HTTP POST. HTTP POST may take the design in an entirely new direction so there may be compelling reasons to support HTTP POST before introducing the remaining resources.
