feature article
Subscribe Now

Code Like an Entrepreneur

It’s Easy to Get Distracted When You’re Knee Deep in Source

“So there I was, at 30 thousand feet…” We’ve all told stories that started like that, even if we were never WWII bomber pilots. Every coder who’s been on the job more than a few years has harrowing tales of late-night shifts, bug-hunting expeditions, and miraculous saves at the eleventh hour. We’ve seen good code and bad code and lived to tell the tale. I’m with you, brother. I’ve been there, too.

We’ve all written the occasional snippet of bad code. There are many reasons: the misplaced typo; the invalid assumption; the momentary brain lapse. But sometimes it’s not just a fleeting mistake. Sometimes we’re not just writing bad code, but writing the wrong code. When you’re knee-deep in the bowels of your own source code, it’s all too easy to forget what you’re writing for. To borrow an arboreal metaphor, we sometimes don’t see the forest for the trees. Worse than that, as coders, we sometimes focus on the nuances of the bark and really can’t see the forest – or the trees.

In the spirit of therapeutic confession, I’ll give you an example of my own screw-up. I was diligently working on a wired communications protocol for an embedded product, and I had been hacking away at it (ahem, carefully crafting fine software for my employer) for many weeks. It was close to working, but there were still a few small bugs that appeared during specific testing conditions. In short, I figured I was about 95% done, when in reality I was probably closer to halfway. At any rate, I had narrowed the problem down to a small set of subroutine calls. The bug(s) had something to do with the way these subroutines interacted with the operating system’s APIs. I figured either (a) there was a bug in the APIs, (b) there was a bug in my code, or (c) there was a bug in the documentation, and I was unwittingly using the API incorrectly. Whatever the cause, I was this close to solving the problem and releasing the code.

Unfortunately, being this close meant exactly nothing. I stayed this close for days. And then weeks. And then a whole month went by and I had almost nothing to show for it. I’d certainly been busy; I’d rewritten and re-tested thousands of lines of code. And I’d learned a lot about the operating system, its APIs, and my compiler. I even learned about new features of the microprocessor I was using. All interesting stuff, but it didn’t actually get me (or my employer) any closer to shipping the damn product.

A small part of me actually enjoyed chasing down those bugs, even though I knew I was behind schedule. It was good, solid, technical work, and it made me a better programmer (or so I thought at the time).

And then it happened. Another programmer wandered by, asked me a couple of questions, and said, “Why don’t you just replace the communications link with shared memory? It’ll go faster, and you can forget trying to solve that API problem.”

Well, duh. He was right, of course, and that’s more or less what we wound up doing. His insight was that, unlike me, he wasn’t up to his eyeballs in implementation details or trying to hammer out a specific fix. He was just trying to solve a problem.

There’s an old story (probably apocryphal) about how the U.S. space program spent millions of dollars developing a ball-point pen that could work in orbit. The NASA astronauts needed to fill out checklists and make notes, and normal pens didn’t work in zero gravity. Eventually, they got their elaborate “space pen” to work and everything was fine. Years later, when the U.S. and Soviet space programs cooperated on Apollo/Soyuz linkups, the question came up, “How did you guys in Russia solve the zero-gravity pen problem?”

“We use pencils,” was the answer.

These are good lessons. Whether we’re running a startup company (or a space program) or not, we need to keep our eyes on the goal, not the implementation details. In product development, it’s the user experience that matters, not the elegance of the code that delivers it. Time spent with your head down chasing a tough technical problem can lead you off track. The bigger the gulf between the customer and the person creating the product, the greater the risk of off-track-ness. Ideally, you cobble together a product, test it on the customer, revise it, and repeat indefinitely. Spending weeks (or in my case, more than a month) falling down the rabbit hole might feel like real work, but it’s likely a big distraction. Focus on the end, not the means.

I can’t be sure yet, but I think the newest negative example of this thinking is Microsoft’s Outlook 2013. One of its many new features is something called “cached Exchange mode.” The idea is to keep the Outlook mail client connected to the server at all times, but to fall back on a locally cached copy if/when the connection fails. The crossover is seamless, in the sense that you can’t tell (and Outlook doesn’t tell you) whether it’s really online or not. That may be nice in concept, but it’s frustrating in practice. Regardless of how elaborate the caching scheme is or how many thousands of man-hours the company spent developing it, the end result is confusing and (in my experience) leads to lost data. Too much focus on implementation; too little attention paid to the user experience.

Don’t forget whom you’re ultimately programming for. And always keep a pencil handy. 

3 thoughts on “Code Like an Entrepreneur”

  1. For example, I was shocked when I read the review about essayshark because I have been using this service for many years, but I accept the point of view of these people because the situations are different. For me, this service is perfect!

  2. Many of the failed projects I took over had similar problems where the original team beat their heads against an insolvable solution for months. Often because they avoided “better” “workable” solutions that they had some false idea that they were “worse” “unworkable” because “everybody” knew they were. Many times because this “better” solution was a very cool, fancy, better than the state of the art miracle solution.

    Get the project done with strict KISS. Once the project is done and management doesn’t have anything pressing for your next project, you can sometimes get approval to spend a few days, or weeks, to explore the research project toward something better. … Probably not, but it does happen at times. Don’t ever put a fancy new research project in the critical path for delivery.

Leave a Reply

featured blogs
Dec 1, 2020
If you'€™d asked me at the beginning of 2020 as to the chances of my replicating an 1820 Welsh dresser, I would have said '€œzero,'€ which just goes to show how little I know....
Dec 1, 2020
More package designers these days, with the increasing component counts and more complicated electrical constraints, are shifting to using a front-end schematic capture tool. As with IC and PCB... [[ Click on the title to access the full blog on the Cadence Community site. ]...
Dec 1, 2020
UCLA’s Maxx Tepper gives us a brief overview of the Ocean High-Throughput processor to be used in the upgrade of the real-time event selection system of the CMS experiment at the CERN LHC (Large Hadron Collider). The board incorporates Samtec FireFly'„¢ optical cable ...
Nov 25, 2020
[From the last episode: We looked at what it takes to generate data that can be used to train machine-learning .] We take a break from learning how IoT technology works for one of our occasional posts on how IoT technology is used. In this case, we look at trucking fleet mana...

featured video

AI SoC Chats: Protecting Data with Security IP

Sponsored by Synopsys

Understand the threat profiles and security trends for AI SoC applications, including how laws and regulations are changing to protect the private information and data of users. Secure boot, secure debug, and secure communication for neural network engines is critical. Learn how DesignWare Security IP and Hardware Root of Trust can help designers create a secure enclave on the SoC and update software remotely.

Click here for more information about Security IP

featured paper

Keys to quick success using high-speed data converters

Sponsored by Texas Instruments

Whether you’re designing an aerospace system, test and measurement equipment or automotive lidar AFE, hardware designers using high-speed data converters face tough challenges with high-frequency inputs, outputs, clock rates and digital interface. Issues might include connecting with your field-programmable gate array, being confident that your first design pass will work or determining how to best model the system before building it. In this article, we take a look at each of these challenges.

Click here to download the whitepaper

featured chalk talk

Maxim's Ultra-High CMTI Isolated Gate Drivers

Sponsored by Mouser Electronics and Maxim Integrated

Recent advances in wide-bandgap materials such as silicon carbide and gallium nitride are transforming gate driver technology, bringing higher power efficiency and a host of other follow-on benefits. In this episode of Chalk Talk, Amelia Dalton chats with Suravi Karmacharya of Maxim Integrated about Maxim’s MAX22700-MAX22702 family of single-channel isolated gate drivers.

Click here for more information about Maxim Integrated MAX22700–MAX22702 Isolated Gate Drivers