I invite you to upgrade to a paid subscription. Paid subscribers have told me they have appreciated my thoughts & ideas in the past & would like to see more of them in the future. In addition, paid subscribers form their own community of folks investing in improving software design—theirs, their colleagues, & their profession. Why does software development start out fast, then slow to a crawl? Why does this happen faster when coding with a genie? What can we do about it? We’re going to play with graphs here for a second. The simplest way to look at our conundrum is to watch the features over time. Rapid progress at first, then stagnation despite our best efforts. Bugs pile up. The build slows. Backwards compatibility imposes its own tax on progress. Original team members move on, while new members take time to acclimate. What’s to be done? Is this just the price of progress? Let’s take the first derivative of features, feature progress over time. Starts out gangbusters, then devolves to occasional bursts of productivity. We’re no closer to a diagnosis or a treatment. We just know that coding with a genie compresses time. Scatterplot
Edward Tufte in Visual Display of Quantitative Information laments that most graphics are time series. If you want to understand the relationship between two variables, you need to plot them with each other, not just as part of the same timeline. We want to understand feature development, so that needs to be one of the axes. I’m going to put it on the horizontal axis, for reasons that will become apparent (I tried it every which way before settling on this—I’m giving you the abridged version). If all we’re looking at is feature progress, we expect progress to be spread apart (fast) at first, then bunch up as time passes. But what goes on the vertical axis? OptionsNo big surprise here, my fellow Tidiers. We know that software embeds economic value 2 ways:
|