Day Off
I’m taking a day off from writing today. See you tomorrow!
(Yes, I understand the irony of this post)
Toaster Apps
Developers may like to write software, but that doesn’t mean we want to fix your computer (or even know how to fix it, for that matter). Nevertheless, we’re often asked, and sometimes try. A former co-worker of mine used to complain about his neighbor’s constant IT requests. “Toaster Lady” he called her, because she’d say “I want my computer to ‘just work’. Like a toaster.”
There’s a lot for those of us in the software industry to unpack in a statement like that. In particular, I was reminded this weekend that getting software applications to the point where they “just work” can be incredibly difficult.
Part of this relates to the phenomenon of simplicity that I’ve written about before. It takes effort to design interfaces that are both simple and functional for a broad range of users. And there’s a temptation to put aesthetics before all else. Resist it (and read Don Norman’s seminal work on the subject).
Implementation of a simple design is not simple. In fact, it’s often tougher to build code that does simple things well, because nothing is simple with computers. Beneath the Google search box lies an unimaginable stack of data, algorithms, networks, and hardware, all of which works together in concert to find that perfect cat video. It takes an army of people to keep it all running (because everything is always breaking all the time). Not to mention the even larger army of people who designed the individual elements, who could only do so because of the work of even more people whose research and ingenuity gave rise to computing machines in the first place. Simple search? Ha, there’s no such thing.
And the work required continues to grow exponentially into testing. All possible permutations of use cases must be tested to flush out potential problems. Have two buttons? Well, that’s four tests. Add a third, now you’re up to eight tests. Oh, and even that isn’t covering that one weird case where if you press the same button fifty times in a row and then hit button three the software crashes. Now expand that to a box with arbitrary text input? The possibilities are staggering (but not endless; there’s a big gulf between large and infinite, but that’s a post for another day).
Consider all of this next time your technology fails you, and be thankful that it ever works at all.
Lesson Learned
When you’re cross-posting your writing to five different social media channels, it behooves you to proofread, especially that first sentence.
Thinking In Future Tense
Last night I was reading an article on characteristics of a good startup, and this nugget jumped out at me (it was originally said by Marc Benioff):
People overestimate what you can do in a year and they underestimate what you can do in a decade.
Software folks tend to be impatient for success, perhaps fueled by seeing the lucky few like Mark Zuckerberg who achieve near-instant greatness. The temptation of moving around to chase pay increases is also ever-present. And it’s really easy to get tired of a particular project at about the 80% complete mark and leave it unfinished (that’s worth a post all its own).
However, great products and great companies almost always take time to develop. And deep satisfaction awaits the person who, through years of toils, takes an idea to completion or builds a fantastic engineering culture. When I was (finally) looking for a change after 12 years at one place, why did I turn down offers from the typical dream companies? Because they’re essentially solved problems, and the chance to make a long-term transformation is minimal.
My current workplace is far from perfect. Without a doubt it’s been more challenging than I expected since I started 3 years ago. But I’m learning to be patient. There’s no guarantee of success, but if it comes, I know it’ll be more satisfying than if it had come quickly.
It reminds me of a story I heard from Andrew Peterson of the designers of Central Park. Told briefly, the folks who planted those first trees knew they would never even see the fruits of their labor, since a generation had to pass before their landscapes could mature. But what a result it was! That kind of patience inspired a great song and it inspires me as well.
Sidenote: the title of this post comes from a book I snatched from the free table outside the library at Judson Baptist Church in Nashville. I highly recommended it (the book, not the church).
Jud’s Law
The quality of a company’s conference room technology is inversely proportional to the quality of the technology developed at that company.
Developers Have Personalities
The first 12 years of my career I worked for a large defense contractor. One of the perks of a big company is opportunities for training, and in 2009 I had the privilege of taking a year-long “front-line” management class. Some of it was corporate drivel, but a surprising majority I found useful. One area of focus was on personality testing and analysis.
Why would that be of importance to managing a software team? Well, as I’ve said before, software is written by humans, and understanding how to get the best work out of said humans is a critical part of management. One way to do that is to learn the personalities of each member of the team.
During the training we used the Myers-Briggs Type Indicator, but the new hotness is the Enneagram. I’ve listened to a podcast and have also started a book on the topic, both of which were particularly focused on the spiritual aspects of self-understanding. But I think there’s plenty of cross-applicability to the world of management, and I look forward to exploring that in the coming days.
P.S. I walk the line between INTJ and INTP, and am either a Five or Nine (still figuring that one out).
The Other Full Stack
Typically when a software person says he is “full stack developer” what is meant is “I can do UI, business logic, and databases.” All well and good, those kind of folks are important to have around.
But there’s another dimension to development that I consider even more useful. Let’s call it the “life-cycle stack”:
“I can write requirements, design, implement, test, deploy, and maintain.”
An engineer who can do everything across that spectrum is tremendously valuable.
More Pascal
“If we look at our work immediately after completing it, we are still too involved; if too long afterwards, we cannot pick up the thread again.”
A big challenge for managing a software development team is the problem of context switching. Interruptions in general are productivity-killers, and it’s especially true of a discipline that requires sustained focus like coding.
But in addition to small-scale interruptions (of the 5-15 minute variety), large-scale switching of priorities can also have a disastrous effect on productivity. I’m thinking here of diversions of the 1 day to 1 week variety. Frederick Brooks couldn’t have been more right:
“How does a large software project get to be one year late? One day at a time!”
(You have read The Mythical Man-Month, right? If not, get thee to a library immediately. It’s required reading for anyone in the software profession).
I do my best to take the above warnings to heart, but it can be tough in the day-to-day realities of production bugs and last-minute requests. One way I try to mitigate is to serve as the buffer between my team and these sorts of interruptions. No doubt there’s a huge cost to my productivity, but I can plan for that when I recognize it as a critical part of my role.
Pascal’s observation has a second application to software development, one held in tension with the “no interruptions” philosophy: sometimes a developer needs to take a break from her current tasking to get refreshed and refocused. This can play itself out in a number of ways, whether it be jumping from front-end to back-end development for a few weeks to avoid getting pigeon-holed, to taking a half-day to go through a tutorial on a new technology, to simply grabbing coffee for 30 minutes and getting out of the cubical. Project planners would do well to build in significant amount of “productive diversions” into their roadmaps, and front-line managers should not get grumpy when they don’t see developers at their keyboards 9 hours straight.
Ultimately my philosophy is simple: trust your team to be professionals, and let the results be your guide.
Anomaly
Don’t think I’ll normally write on weekends, but thought it worth stopping by to say so, lest my throngs of anxious readers go wondering.
Wisdom Of Pascal
“I would have written a shorter letter, but I did not have the time.”
Blaise Pascal was a smart dude. Much of what he had to say is surprisingly applicable to software development (which is why if you show me a well-read developer I’ll show you a good developer). The above quote came to mind yesterday during an all-hands meeting where we were discussing our company core values:
“We build elegantly simple software.”
I love that sentiment. But make no mistake: elegance and simplicity take more time to build than complexity. This is true up and down the process, from prototyping, to requirements development (holy cow is this step often rushed; we’d do well to heed Mark Twain here), to implementation and testing.
My first task after moving to San Diego was to help a development team push through a particularly challenging set of features for a digital mapping system. Twelve hour days and weekend work was expected, and all tasks had to be done as quickly as possible. The technical architect had put together a mockup of a few of the screens using a prototyping tool, and unfortunately the quickest way to make those screens a reality was to copy and paste the auto-generated XAML (sort like Android’s XML-based UI markup, but for C#) and then tweak it. This led to a ton of duplication, with hard-coded screen positions everywhere. By the time we got the initial release of the application to the test team, it had become an unmanageable nightmare. But we limped along, duct taping bugs as they came up.
Then came the back-breaker, under the guise of a single requirement: “by the way, this needs to work in landscape as well as portrait orientation”. Just like that, our brittle implementation became untenable. It needed a complete re-write.
I was assigned the task, and (thankfully) given a month to do it. My delete key was never busier as I learned how to abstract and consolidate the XAML, replacing tons of repeated values and cleaning up duplication. Turns out XAML is pretty easy to author and has plenty of features for writing clean and responsive implementations, but no one had bothered to learn it. By the end of my process, in addition to adding a landscape capability, I’d shrunk the code base by over 90%, and gained a near 5x boost in performance to boot.
The moral of the story? Well, actually there’s two. The first is that using SLOC is a dumb measure of productivity (I was averaging about -10,000 lines written per day or something like that). And the second is that the best developers delete as much code as they write. Maybe even more. Refactoring isn’t a separate step on the task list; it’s part of every task. Yes it takes more time. Yes you might need to let go of your ego and trash that super clever function when it becomes unneeded. But your product will be better for it.