The existence of these paradoxes doesn’t mean things are hopeless. I don’t point them out to frustrate or depress you. Every day, paradoxically, teams still build and ship working software.
I point them out to make sure we realize that they exist, that we need to accept them and deal with them, and hopefully avoid the pitfalls and potholes that they present. We can’t eliminate the strangeness and chaos, but we can anticipate them and deal with them. Our job is to ship despite them.
One last paradox might be that software is never really done. There is always one more feature that you can add. At least with a bridge, it is quite clear when the job is finished and that the product works as designed. {font-family:”Cambria Math”;panose-1:2 4 5 3 5 4 6 3 2 4;mso-font-charset:0;mso-generic-font-family:roman;mso-font-pitch:variable;mso-font-signature:-536870145 1107305727 0 0 415 0;}p.MsoNormal, li.MsoNormal, div.MsoNormal{mso-style-unhide:no;mso-style-qformat:yes;mso-style-parent:””;margin:0in;line-height:115%;mso-pagination:widow-orphan;font-size:11.0pt;font-family:”Arial”,sans-serif;mso-fareast-font-family:Arial;mso-ansi-language:EN;}h4{mso-style-priority:9;mso-style-qformat:yes;mso-style-link:”Heading 4 Char”;mso-style-next:Normal;margin-top:14.0pt;margin-right:0in;margin-bottom:4.0pt;margin-left:0in;line-height:115%;mso-pagination:widow-orphan lines-together;page-break-after:avoid;mso-outline-level:4;font-size:12.0pt;font-family:”Arial”,sans-serif;color:#666666;mso-ansi-language:EN;font-weight:normal;}span.Heading4Char{mso-style-name:”Heading 4 Char”;mso-style-priority:9;mso-style-unhide:no;mso-style-locked:yes;mso-style-link:”Heading 4″;mso-ansi-font-size:12.0pt;mso-bidi-font-size:12.0pt;color:#666666;}.MsoChpDefault{mso-style-type:export-only;mso-default-props:yes;font-size:11.0pt;mso-ansi-font-size:11.0pt;mso-bidi-font-size:11.0pt;font-family:”Arial”,sans-serif;mso-ascii-font-family:Arial;mso-fareast-font-family:Arial;mso-hansi-font-family:Arial;mso-bidi-font-family:Arial;mso-font-kerning:0pt;mso-ligatures:none;mso-ansi-language:EN;}.MsoPapDefault{mso-style-type:export-only;line-height:115%;}div.WordSection1{page:WordSection1;}]]> Civil engineers can rightfully claim that notwo bridges are exactly alike. However,bridges share many known characteristics, and the materials they are built withhave known characteristics. What they dohas many known knowns and not as many unknown unknowns as one might think.I am not a civil engineer and I have nothing but respect for the fine folksthat design and build our bridges, but I point this out to contrast it towriting software. Writing good,functioning software is hard. Every project undertaken by software developmentteams has never been done before. Thereare similarities amongst projects, sure, but any given project has nuances,requirements, and a plentiful supply of unknown unknowns. Or, one might say, software development isfull of paradoxes that are challenging to deal with. Here are four:No one knows how long anythingwill take. Customers want and need toknow how long things will take. This, frankly, is probably the biggest challenge that software developmentorganizations face. We simplyaren’t able to tell for sure how long any project will take. Sure, we canestimate, but we are almost always wildly off — sometimes drasticallyoverestimating, but most often drastically underestimating how long somethingwill take. But for our customers, this is both a mysteryand a difficulty. Not understanding thefirst part of the paradox, they don’t get why they can’t know for sure whenthey will have a new piece of functionality and are of course frustrated whenit isn’t delivered as promised. We try story points and planning poker and allkinds of other agile techniques to figure out when things will get done, but wenever quite seem to be able to get past Hofstadter’s Law: “It always takes longer than you expect, even when you take intoaccount Hofstadter’s Law.”Brooks’ Law — Adding developersto a late project makes it later. This is the strangest of the paradoxes to thecasual observer. Normally, if you realize that you aren’t going to make the deadline for filingyour monthly quota of filling toothpaste tubes, you can put more toothpastetube fillers on the job and make the date. If you want to double the number of houses that you build in a givenyear, you can usually double the inputs — labor and materials — and get twiceas many houses, give or take. However, as Fred Brooks showed in his book The Mythical Man Month, “adding manpowerto a late software project makes it later.” That is a paradox, but it’s as close to a law in software development aswe will get. Brooks showed that becausenew team members require training, time to learn the context of a complexsystem and increase the communication overhead, they can’t contribute to theproject immediately, thus driving up costs. The better you get at coding, theless code you end up writingIt takes many years to gain experience as asoftware developer. Learning the rightway to code, the right way to design, and all the small subtleties of writingclean, maintainable software isn’t done overnight. But all too often, as you gain thatexperience, you are put into leadership positions that actually reduce theamount of code that you write. Instead,you end up in design meetings, reviewing code written by others, and managingpeople. And sometimes you get promotedout of writing code all together. That is not to say that a senior developer’scontribution decreases — that is usually not the case. The process of planning projects, mentoringyounger developers, enforcing coding standards, and realizing how important itis for everyone to write good code — all contribute mightily to the success ofa project. But you still end up writing less code. Software development frameworksand tooling keep getting better and more powerful, but our software still takesjust as long to develop and never seems to run any faster. If you compare how we build web applicationstoday with React,Astro, Next.js, andother powerful advanced tools with thirty years ago when we processed data andHTML using the Common Gateway Interface (CGI), you soonrealize that we’ve advanced lightyear from those early days. It always seems like a paradox to me that ourprocessors get faster and faster, but software development never seems to moveany faster. Work always seems to expandto fill and exceed not only time budgets, but every single CPU cycle as well. Our sites look nicer, but are we really anymore productive? Do our sites run fasterand process data better? Sure, these newframeworks and libraries abstract away many complexities (does anyone want towrite jQuery code anymore?) but at thesame time introduce new problems like long build pipelines, configurationnightmares, and dependency bloat. The existence of these paradoxes doesn’t meanthings are hopeless. I don’t point them out to frustrate or depress you. And yet, every day, teams still build andship working software. I point them out to make sure we realize thatthey exist, that we need to accept them and deal with them, and hopefully avoidthe pitfalls and potholes that they present. We can’t eliminate the strangenessand chaos that they can present to us, but we can anticipate them and deal withthem. Our job is to ship despite them. One last paradox might be that software isnever really done. There is always one more feature that you can add. At least with a bridge, it is quite clearwhen it is done and that it works as designed.