In Praise of the Solo Programmer

HughPickens.com writes: Jean-Louis Gassée writes that once upon a time, we were awestruck by the solo programmer who could single-handedly write a magnum opus on a barebones machine like the Apple ][ with its 64 kilobytes of memory and an 8-bit processor running at 1MHz. Once such giant was Paul Lutus, known as the Oregon Hermit, who won a place next to Jobs and Wozniak in the Bandley Drive Hall of Fame for his Apple Writer word processor. "Those were the days Computers and their operating systems were simple and the P in Personal Computers applied to the programmer," writes Gassée. "There's no place for a 2015 Paul Lutus. But are things really that dire?"

As it turns out, the size and complexity of operating systems and development tools do not pose completely insurmountable obstacles; There are still programs of hefty import authored by one person. One such example is Preview, Mac's all-in-one file viewing and editing program. The many superpowers of Apple's Preview does justice to the app's power and flexibility authored by a solo, unnamed programmer who has been at it since the NeXT days. Newer than Preview but no less ambitious, is Gus Mueller's Acorn, an "Image Editor for Humans", now in version 5 at the Mac App Store. Mueller calls his Everett, WA company a mom and pop shop because his spouse Kristin does the documentation when she isn't working as a Physical Therapist. Gus recently released Acorn 5 fixing hundreds of minor bugs and annoyances. "It took months and months of work, it was super boring and mind numbing and it was really hard to justify, and it made Acorn 5 super late," writes Mueller. "But we did it anyway, because something in us felt that software quality has been going downhill in general, and we sure as heck weren't going to let that happen to Acorn."

Comments

Its easier now

[Anonymous Coward]

Once upon a time you had to write a type renderer if you wanted to write a wordprocessor, now the OS does that for you.
Once upon a time you had to drive the audio directly, now the OS does that.
3D? You had to write your own stack, now OS does that.

Really its a LOT easier for one person to write a full app these days, and behind a lot of those mega teams you'll find there is actually one person doing the heavy lifting.

I find it trivial to do major apps these days.

Re:Its easier now

[ILongForDarkness]

The problem is there is trivial and then there is trivial. Yeah you can get a notepad clone up and going quickly. But if you want to compete with other editors that are out there for free you need to add syntax highlighting, efficient support for large files, likely tabbed content support, fonts, good search, potentially regex support etc. In short: we rarely need to create something completely new now. But we have an endless list of required features to compete. Often few are technically difficult to implement just a huge amount of work to get through and lots of nit-picky things like borders on controls rendering differently on different browsers and the like. You're not solving one of lifes mysteries but you still might burn a week figuring out why one does it different than the other and finding what magic combo makes all browsers happy at the same time.

Mobile apps

[fluffernutter]

Surely there are a great many people out there who develop both android and iPhone apps, along with the web site and server that they go with. I didn't think the 'solo programmer' was an uncommon thing.

The romance of the code ninja

[quietwalker]

- Silently checking in 12000 lines of code in the middle of the night and leapfrogging the entire development schedule by months.
- Spending 72 consecutive hours at the keyboard, sustained by caffeinated drinks and a desire to produce an end product that will make your users - and other programmers say 'Wow!'
- Delving into the voodoo and deep magic of a system, consuming it all and spitting it back out with ease, and being regarded with awe by your peers.

Yeah, these are awesome. The Story of Mel was an early encouragement to me; between it and the movie Tron, it put me on the path to being a software developer.

Lots of folks pointed out pro- arguments, so I won't cover those, but there are an awful lot of cons. 20 years plus into my career, I'm seeing some fatal flaws.

The first is the Bus Factor. A solo developer, whether in a group or not, does not facilitate the dispersal of knowledge. There's a difference between documentation - even the elusive technical documentation - and knowledge, and that gulf widens with each feature, bugfix, and release. In my experience, when a solo developer leaves - for whatever reason - it's often easier to start from scratch than try to maintain their software.

That leads us to the next issue, maintainability. As was described above, a solo developer can skip quite a bit; coding style, documentation, modularization, naming schemes, readability, unit testing, automated build and deployment, and so on. I've had to take over so many projects in my life that required more time to set up a working build and test environment than they did to fix the error I had been brought in to tackle. I used to carry a pack of cd's with precompiled versions of sed, awk, as, and other tools for various *nix platforms (and versions of those platforms) because these were often not just pre-requisites for the often complex script-based builds, but often only came in for-pay packages that weren't on the machine I was expected to work off of. I had a set of about 30 just for HP-UX alone (because you have no idea which version-specific behavior a given build relies on). Put it this way: every build required a port.

Of course, it's not just other people's code. I'd come back to something I wrote a year prior and it'd be horrible.

"Why did /THEY/ do this? Wait ... did I do this? Geeze, I USED to write bad code." - me, every. single. time.

I have a theory that only constant modifications to code keeps away the gremlins that cause bitrot. Leave a piece of code alone for a month, no commits (assuming you're even using version control), and they come in and crap all over your beautiful hacks and graceful architecture, rendering it just barely capable of doing what it was designed to do, and sometimes not even that. Yet, you write your code as if a team will handle it, losing most of the benefits of being a solo dev, and it's usable when you come back to it later.

Communication is next, and it ties into the maintainability above, but on a software development lifecycle level. When someone is silently making architectural changes and off doing their own solo thing, sure, they get a lot done. When you're completely by yourself, that's fine. What happens though, when you're doing solo development in a large company? Suddenly there's no code reviews, no understanding of department or organization architectures, or even just updates to them. Your code usually stands on the back of a whole architectural stack, and without two-way conversations, it isn't guaranteed to hold up. It's not just that you might accidentally reinvent the wheel - it's that you could do it wrong and limit the application (or have it die) later, with an expensive to fix systemic issue. Documentation fits in this category too - and why do documentation when you're a solo dev? You can always answer any question, right? Yo