Slashdot Mirror
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."
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."
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.
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.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
This book has some great stories of the days when solo programmers reigned: http://www.amazon.com/Hackers-... It still blows me away that some of my favorite games from Sierra, etc were designed and coded by one person (art and all) while today you can't make a video game without a team of hundreds.
He can write a C++ compiler using only javascript.
He can build a robust modern MMO with no bugs in 2 days, using only a Commodore 64 and a case of Red Bull.
He can promise an application to solve all your company's problems, and actually deliver it !!
And he always puts pros before hoes
He's Davy, Davy Brogramar...master of all programming!
SJW's don't eliminate discrimination. They just expropriate it for themselves.
"I once preached peaceful coexistence with Windows. You may laugh at my expense - I deserve it."
-- Jean-Louis Gassee, CEO Be, Inc.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
In a way, Notepad++ was written by one person, right?*
*With a handful of contributors since 2014?
Or the quite unknown Hiawatha webserver. A very good alternative to the well known Apache webserver and completely written by one person.
It doesn't have to be like this. All we need to do is make sure we keep talking.
- 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
The Apple ][ plus had 48K of regular RAM and an expansion slot 0 for the 16K RAM expansion card (known as the "language card" because it enabled Pascal to run on the machine). The older Apple ][ did not have this slot, and maxed out at 48K.
The Apple //e came with 64K built in, but still arranged as above for compatibility. Whereas the earlier DOS fit within the 48K space, the more feature-full ProDOS occupied the language card space and thus required a 64K machine.
The Apple //e replaced slot 0 for a specialized slot for an 80-column card, and the latter came in two flavors, the "extended" one carrying another 64K of RAM which could be accessed through yet another form of bank-switching. One the of the best known apps to take advantage of this was Appleworks.
Third-parties like Applied Engineering expanded on the idea of the extended 80-column card with products like Ramworks, which provided additional 64K bank-switchable banks all the way up to a total of 3 megabytes, useful for ram-disks and so that Appleworks could load it's entirety into RAM. Even at 1MHz, an Apple // operating entirely under ram-disk seemed darn-well snappy.
Take it easy, Charlie, I've got an Angle...