Harder Than It Looks
Simple is hard. Consider the following:
I guarantee an order of magnitude more work went into the first two of these three interfaces.
Finish
Does anyone else have a hard time finishing a project? I suspect it’s a common theme among developers. At the beginning, a project is fresh and new, and it’s fun setting up new tools, cleaning the slate, and getting that first prototype up and running. But as time goes on and the needed features pile up, excitement wanes. Your clean initial bits of code have been cluttered by refactoring and redesign as requirements evolved and unexpected complexities emerged. What was once new is now routine when you’re adding feature 42 of 50, and by the time a task is 90% done, you’re tired of looking at it and desperate for something different.
You’re not alone in this feeling; it’s a well documented phenomenon across a variety of creative disciplines. But fight that tendency, my friends, and push through, because a finished imperfect project is better than a perfect unfinished one.
My theory is that the inability to finish is a combination of the 80/20 rule, unavoidable code rot, and the Creator’s Curse. Naming these issues is the first step to mitigating them, so don’t be afraid to call them out when you see them, both on your team and especially in your own work.
I know personally it was a barrier to getting this blog going again, and it’s a problem I still fight. Am I totally happy with this post? No, not really (writing it while trying to listen in on a teleconference doesn’t help). But I’m clicking publish anyways.
Every. Single. Time.
Want to know what happens if you don’t follow the Boy Scout Rule of software development? This.
That being said, it can be really easy to get into a vicious cycle of constant rewriting and never releasing. We’ll talk about that tomorrow.
Scouts Honor
Yesterday we looked at how theology can inform software development, today we consider physics. The second law of thermodynamics states:
The total entropy of an isolated system can only increase over time.
This statement has a specific technical meaning which is worth investigating on its own merits, but the general principle is that systems tend towards decay. Software systems are no exception to this rule, variously described as software entropy or code rot. Anyone who has worked with software for any length of time knows firsthand how clean code quickly devolves into spaghetti.
How can one combat this seeming inevitability? The key lies in the second law and the little phrase “of an isolated system”. Essentially entropy can be held steady or even reversed in a system if it is properly influenced from outside that system. In the world of software this means that every time a change is made, one should not just do the minimum required to implement the change, because any edit likely increases entropy. Instead the developer must go further to leave the code better than she found it (what Uncle Bob described as the Boy Scout Rule). The best developers work to make this second nature.
Yes this takes more time in the short run. But it’s essential to the long-term health of a software system.
Missing The Mark
Yesterday I made a broad claim about the applicability of various subjects to the task of software development. Today I want to give a specific example from the realm of theology.
The notion of sin is foundational to a number of world religions. Without belaboring the details or arguing the validity of any one definition, what cannot be disputed is that humans have been wrestling for a long time with their own limitations. Why is it that none of us are able to live up to our own ideals, let alone the ideals of a faith tradition? Why must it be that “nobody’s perfect”? To quote Saint Paul,
I do not understand my own actions. For I do not do what I want, but I do the very thing I hate . . . I have the desire to do what is right, but not the ability to carry it out.
Great stories confront us with the fickle imperfections of human nature as well. Is not human frailty and the conflict that arises from it the very foundation of an epic tale? Nothing proves this truth quite like “fiction”.
What does this have to do with software? Let me repeat myself: software is made by humans, and the results are subject to their constraints. That means you can expect both errors of omission and commission, and both unintentional mistakes (e.g. a developer fails to adequately review code) and deliberate laziness, cheating, pride, etc. One certainly hopes for few instances of the latter, but they do happen. It’s not just time you have to plan for.
A process must be designed to recover from its own imperfect implementation, else it is doomed to fail.
Like Eating Your Vegetables, But Better
Good software engineers read. And not just technical blogs or books on coding, but on all manner of subjects. Politics, mathematics, philosophy, science, history, and theology have much to contribute to the work of professional software development. But even more important to cultivating a healthy creative mind is the reading of fiction.
Maybe it’s just me, but I feel that a rich diet of fiction has fallen out of favor in our culture, especially in contrast to the consumption of technical information. That’s unfortunate, for stories have a unique power to shape the mind. For me, classic science fiction in particular has inspired me to consider how technology can be of benefit to humanity, and warned me of ways it might be a danger. No O’Reilly book is going to tell you that.
While I’m on the topic, can I say how much it bothers me that we categorize books as “fiction” and “non-fiction”? Those are horrible labels. Novels and other stories can communicate truth in a myriad of ways, and it’s quite possible for non-fiction to be either mistaken or outright false. If you tell me “I only want to read things that are real, not fake” I will absolutely make fun of you. Consider yourself warned.
Writing On A Saturday?
Show yourself grace, but get back on the horse as soon as possible, right? Fortunately I happen to have some free time this morning. Did the breakfast dishes while listening to some Pink Floyd, which took me right back to high school when I was an obsessive fan (circa “The Division Bell”). It got me reminiscing as well about the various kinds of software development I’ve done over the years. Here’s some significant milestones:
- Age 4: Dad buys our family its first computer, a TI-99/4A
- Age 5: Someone gives me a green paperback with a bunch of Basic programs; I spend hours typing them into the computer and figuring out how to print the American flag in ASCII characters, among other things
- Age 7: I’m a regular at the local library’s “programming” section, and start writing simple games (still on the TI computer, and still all in Basic)
- Age 9: My first upgrade: a Tandy 1000 TL/2 from Radio Shack; within a few days of having it at home I inadvertently format the boot disk, bricking the machine
- Age 10: Now having the ability to save programs to floppy disk, I get pretty into QuickBASIC, especially fiddling with the game Gorillas
- Age 11: We upgrade again, to a Tandy 386, with an internal hard drive and VGA graphics; somehow my parents think it’s a good idea to put the computer in my bedroom
- Age 12: I teach myself C, and begin memorizing powers of 2 (up to 65,536) and digits of Pi (3.14159265)
- Age 14: I take a correspondence course in Pascal, where I learn legitimate structured programming; lacking email or the Internet, I printed out code and mailed it to my teacher
- Age 16: Wanting to keep a secret journal, I write an encryption algorithm (a substitution cipher that would have worked reasonably well had I not used Pascal’s built-in pseudo-random number generator); but it was enough to keep my sister out
- Age 17: The Internet happens; “hijinks” ensue of which I will speak no more
- Age 18: Now running a Pentium 2, my dad comes home from work to find I’d completely disassembled the machine; he was not pleased, but I put it right back together again without issue
- Age 19: I take my first college course (C programming); it was interminably boring
- Age 20: VisualBasic comes so quickly to me that I finish the entirety of the class’s projects in a couple of weeks; I was so brazen I told the professor I had no intention of coming to class the rest of the semester except to take exams (still got an A)
- Age 21: Compilers, number theory, combinatorics, and linear algebra give me all kinds of new programming ideas; I spend gobs of my free time optimizing an algorithm to compute the largest possible determinant of an nxn binary matrix
- Age 22: I write a Monte Carlo Simulation to determine if there’s an advantage to having the first turn in Monopoly (spoiler alert: there is); I also get hired by TRW
- Age 23: My boss hands me a book on Ada and tells me I have 2 weeks to learn it; I do so by porting a bunch of my college work, in particular a Number Jumbler solver
- Age 24: During my time at graduate school I make side money doing LaTeX typesetting
- Age 27: Now back at Northrop Grumman, I build an algorithms doing terrain analysis and flight path optimization (still in Ada)
- Age 28: Ada goes the way of the dodo, and I’m porting stuff to C; I’m also starting to get into mapping software and learn the “right” way to compute distances on the Earth’s surface
- Age 29: I write my favorite single piece of code ever (ask if you’re curious)
- Age 30: My first visit to San Diego, where I give a presentation on my flight path algorithm
- Age 31: I spend way too much time working on a huge proposal that we end up not submitting
- Age 32: We move to San Diego and I get my first taste of technical leadership; I also start learning the basics of HTTP API design
- Age 33: Thinking of making a job change, I go to my first interview since college; it does not go well, and I decide to take a couple classes on web development at SDSU to beef up my resume
- Age 34: I convince my management to buy an 84″ touchscreen for our mapping application; we make the interns assemble the stand
- Age 35: After nearly 13 years, I take my second job at Everyone Counts who I somehow tricked into believing I knew Java (which I’d learned in college but hadn’t seriously used since)
- Age 36: I mistakenly reveal I took a class in Perl at SDSU, which I eventually use to become the technical lead for the company’s voting application
- Age 37: It’s a year of learning, as I get a Code School account and get smart(ish) on Angular, Node.js, and Docker, among other things
- Age 38: I revive this blog and decide to write a bulleted list of my history of software development
Well, that was fun (for me, at least); I probably could have doubled the length, but I’ve already spent too much time on it. If you’ve read this far, I thank you!
Save Something For Grace
I was busy today doing actual work. It happens. See you Monday!
Babies With Great Personality
Yesterday I was speaking with a fellow engineer about the state of our new user interface implementation. We’d crossed a major functionality threshold, but there were still several obvious bugs. I argued that the significance of the functions that were working merited deploying to our integration server for others to see, but he resisted saying that he’d rather wait until a couple of the blatant problems were ironed out.
The above is a common conundrum for developers. Put your work out there for others to see too soon, and they’ll be quick to point out all the flaws. Wait too long, and managers start breathing down your neck because they’re not seeing tangible results.
Personally, I think the wise manager understands the idea of a work in progress, and should appreciate seeing said progress without getting overly critical of early blemishes. It’s a bit like posting photos of a newborn baby. Obviously everyone loves their little nugget, but reality is most newborns aren’t super cute in their first couple of days. But would anyone ever dare point that out to proud parents? Let’s surely hope not! The birth of a child is a momentous event to be celebrated; there’s plenty of time later for the kid to grow into his adorableness.
Likewise a software application. Publish early, and let that baby grow!
The Fire In Which We Burn
Everything takes time.
- Reading and responding to emails takes time
- Checking Slack takes time
- Updating JIRA takes time
- Peer reviewing code takes time
- Writing documentation takes time
- Managing versions and branches takes time
- Meetings and discussions take time
- Keeping a workspace organized takes time
- Updating a computer takes time
- Addressing HR concerns takes time
- Performance evaluations take time
- Eating lunch takes time
- Going to the bathroom takes time
- Mental breaks take time
- Thinking takes time
Plan accordingly (which also takes time).