Heading image for post: The nature of software and fixed bid contracts

Process

The nature of software and fixed bid contracts

Profile picture of Chris Erin

Software is abstract. It is soft, where is it? I can not hold it in my hands or feel it's weight. Is it substantial, insubstantial? Are you impressed by the effort I put into it? Are you disappointed in my apparent slowness while making this software?

Before I write software for you, I am confident that it will be wholly unique. Never before will it have been written, or else why would you want it? If it's not unique, can you instead purchase it elsewhere? Even if it exists, you can't purchase it, and you'd like me to recreate it, I cannot duplicate someone else's software bit for bit. That's like trying to act Patrick Stewart's MacBeth in a way that's indistinguishable from Patrick Stewart. With my first breath I will have failed. I have not lived Patrick Stewart's life, my voice box and diaphragm are different dimensions, and my soul has not acquired the gravity of an actor with his experience.

With my first keystroke, the software I write becomes unique. Everytime I start a fresh project, I am standing on the shoulders of giant bugs whose exoskeleton accretion accelerates constantly. The compiler has been updated, my computer's operating system has been updated, the terminal I use has been updated, the editor, the shell, the browser, the massive ecosystem for my language of choice has been updated. Millions of lines of software have changed since I last started anew. I could not have the written the same "Hello World" today that I did six months ago.

Maybe that is opaque to you. You can't see that the whole world is shifting under our feet with every step. Software is abstract, you can't observe the intangible structures beneath the interface. But trust me when I say that each piece of software is unique.

From your vantage point, the shape of the software you'd like me to create looks like a square to you, but to me it's an infinitely expanding fractal that changes with each magnification. And with each zig or zag I have a decision to make: Can I do this with an if statement? Maybe pattern matching fits? A class might be more communicative. Communicative to who? to me? the next developer? Would you like the software I write to be written for an additional audience, which is every developer that will come after me if this software is successful enough to see a stream of developers, junior, senior, Java devs, C++ devs, devs that have been coding since their family purchased a used Commodore 64, devs that went to a code boot camp after a 10 year career in sales? How could those developers even read a line of code in the same way?

No developer given the same task will make these same microdecisions the same way. Writing software maps our minds as nicely as writing prose or poetry. It can be written to adhere to strict ideals, or it can be written to flaunt those same strict ideals. Do they even matter? Are your opinions about responsibility in software design the same as mine? Do those ideals matter after 5pm when I'm tired, you expect something by tomorrow morning, but the internet has been sketchy and I can't get to the documentation I need?

I make thousands of microdecisions every day on top of a handful of major decisions and while I am a confident programmer I'm not sure that every decision I make is as finely balanced as I would like. Defects are endemic in software and every developer creates defects. Sometimes the defects are due to wrong decisions but sometimes they are due to ignoring entire sets of circumstances. Every defect has its own depth and bredth and story and many are insidious.

Forgive me for saying this, but I am not confident in every decision the person defining what the software should do is making. That person could be you, and again, I am sorry. I have never met a person who could conceive of every detail in full and I have never met a person capable of communicating that vision to a developer. This is why we talk about iterative development. I build something, I show it to you, I ask you if this is what you want, I ask you to verify that you looked at it, and I ask you to tell me how it should change. We iterate on every single feature like this. You detail the course, I travel in a straight line for a day, and you look at the stars and correct the course. Every day.

Given this description of software, how can I tell you the exact time it will fully realize your vision? There are so many variables, variables in me, variables in you, variables in the industry, variables in the software we depend on, and maybe it's not fair to say the course you have charted is the exact course that will accomplish the goals. I can give you an estimate; you deserve an estimate; and you deserve clear daily communication about all the choices we're making but if the course we chart takes detours I cannot work for free. This is why fixed bid contracts are bad.


Image by unsplash-logoKyle Wong

More posts about Process Contracts

  • Adobe logo
  • Barnes and noble logo
  • Aetna logo
  • Vanderbilt university logo
  • Ericsson logo

We're proud to have launched hundreds of products for clients such as LensRentals.com, Engine Yard, Verisign, ParkWhiz, and Regions Bank, to name a few.

Let's talk about your project