Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Programming IT

In Praise of the Solo Programmer 114

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."
This discussion has been archived. No new comments can be posted.

In Praise of the Solo Programmer

Comments Filter:
  • ... those with original ideas

    We get to enjoy so many wonderful things, every single day of our lives, because of those who came up with original ideas - and work to make their ideas become reality

    Solo programmers with original ideaas deserve praises - as for those who can't or don't - nothing special, reaslly - as they are just like all the millions of data monkeys throughout the world

    • by Anonymous Coward

      " Once such giant was"

      How about something entitled "In Praise of the Solo EDITOR" ???

      Oh wait, this is slashdot.

  • Its easier now (Score:5, Insightful)

    by Anonymous Coward on Thursday August 27, 2015 @07:24AM (#50401229)

    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.

    • by Viol8 ( 599362 )

      "I find it trivial to do major apps these days."

      You'll be able to give us a link to some of them then won't you.

    • 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.

      The old Silver Bullet.

      Never happened. They keep moving the goalposts. With the resources available these days, it would be fairly easy to create a WordStar in short order - as long as you didn't expect the original WordStar's resource frugality. But a modern-day app needs to run in a windowing system. And have menus, dialogs and toolbars. And interact with all sorts of programs. And handle lots of file formats. And be Internet-friendly. And have this "essential" feature and that "essential" feature. And so

    • by edremy ( 36408 )
      It's also a lot easier when you start from scratch and don't have to support any old versions/file formats. The bad decisions you make on day 1 (and you *will* make them, no matter how good you are) are going to haunt you for the rest of your life.
    • It's much easier now. Browsers have trained users to a standard set of basic interactions (this used to be a massive obstacle for new programs). Databases, combined with modern storage capacities and CPU speed, have eliminated massive amounts of work. The languages are both safer and more powerful, and less tied to specific hardware. Deployment is trivial via the web. I can do more now by myself than the good team of developers I led were able to produce 30 years ago. There are certainly plenty of pro
    • So essentially what you're saying is that there are no solo programmers anymore. Everybody's work depends on everybody else's work.
  • Mobile apps (Score:5, Insightful)

    by fluffernutter ( 1411889 ) on Thursday August 27, 2015 @07:28AM (#50401253)
    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 guy who wrote Flappy Bird had no problem doing it himself-- he just couldn't handle the success.
    • by Tom ( 822 )

      There are, but at least the ones I know do rely on other people. For example they will buy assets (icons, sound effects, whatever) or get ready-made-libraries for many tasks.

  • Hackers (Score:5, Interesting)

    by crow_t_robot ( 528562 ) on Thursday August 27, 2015 @07:40AM (#50401305)
    This book has some great stories of the days when solo programmers reigned: http://www.amazon.com/Hackers-... [amazon.com] 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.
    • by Anonymous Coward

      ... while today you can't make a video game without a team of hundreds.

      You can. Check 'Indie game: the movie'.

      • I've seen the documentary and it was pretty awesome but as soon as each programmer gets the game to early alpha they have to start bringing in other people to finish the game up to get it ready for release.
  • Sample Programs: http://www.qb64.net/forum/inde... [qb64.net]
    Another place with programs: http://www.thejoyfulprogrammer... [thejoyfulprogrammer.com]
  • by NotDrWho ( 3543773 ) on Thursday August 27, 2015 @07:58AM (#50401387)

    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!

  • by DNS-and-BIND ( 461968 ) on Thursday August 27, 2015 @08:08AM (#50401457) Homepage

    "I once preached peaceful coexistence with Windows. You may laugh at my expense - I deserve it."

    -- Jean-Louis Gassee, CEO Be, Inc.

  • by peon_a-z,A-Z,0-9$_+! ( 2743031 ) on Thursday August 27, 2015 @08:13AM (#50401479)

    In a way, Notepad++ was written by one person, right?*

    *With a handful of contributors since 2014?

    • Notepad++ is based on Scintilla. The point as made above by other posters it is easier today to write major public visible applications using libraries and other code source. Not to take away from the significance of the accomplishment of the author of Notepad++.

  • It's not famous or widely used, but my pet project MSS Code Factory [sourceforge.net] started in 1998 and has kept me busy ever since. I think I'll finally be finished with it this year, though. I think it's time to find something new to occupy my mind and my time with. :D

    • by lannocc ( 568669 )
      Your project looks interesting, thank you for the link. As a Java/XML/DB guy myself I realize the importance of good tools for turning business processes and workflows into working prototypes and overcoming the verbosity of these languages. I'm now following your project on Github and hope to install it and try it out soon. Best wishes!
  • The Apple ][ we had had a 64k address space, true. But it was bank switched. Main memory was 60k, as I recall, but the top 4k had an OS function to select an additional 60k that would map into the low-order 60k. So you had a high 4k permanent bank and two low switched banks of 60k each.

    If you stuck to BASIC you never knew this was going on, and maybe it was only the later machines that did this. But us 6502 hackers knew it. A total of 124k.

    It was many years ago; I think it was the top 4k but it might

    • by mark-t ( 151149 )
      The Apple ][ had only 48K of regular RAM. There was 4K of IO-mapped space, and 12K of ROM. With a ram expansion card, could could map the 16K of additional memory using bank switching into the top 12K rom area. In practice, most software did not use this area. When ProDOS came out, the area was not available for end-user programs at all, since it used this space.
      • The Apple ][ plus [wikipedia.org] 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 [wikipedia.org] to run on the machine). The older Apple ][ [wikipedia.org] did not have this slot, and maxed out at 48K.

        The Apple //e [wikipedia.org] 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 specia

        • by mark-t ( 151149 )
          You are right... it was the Apple ][+ that could utilize the 16K ram expansion card. My bad. My first experience with an Apple was on a ][+, and I sometimes forget about the +.
          • Same here. The green "plus" on the name plate didn't stand out too much. My school library got one with a color composite monitor, paddles, two floppy drives, an Epson printer, and the fantastic documentation (Applesoft Tutorial, Apple ][ Reference Manual) but needed some kid to help with how it works. After I showed 'em how to boot "Oregon Trail" and "Lemonade Stand", they let me use it whenever it was free. Awesome.

  • by Aethedor ( 973725 ) on Thursday August 27, 2015 @08:21AM (#50401531)
    Or the quite unknown Hiawatha webserver [hiawatha-webserver.org]. A very good alternative to the well known Apache webserver and completely written by one person.
    • Webservers are fairly easy to write from scratch.......you can write one in a day (with basic functionality). The time-consuming part is when you add all the bells and whistles and features. Adding the ProxyPass feature to your webserver (like Apache has) will take yet more time.
  • Another variation on the same story we get here every month or so. "Such-and-such is so complex now that the individual is no longer able to contribute anything truly new, as the stuff that one person can do on their own has already been done." That's the price of technological progress, people.

    Sure, the exceptions jump out at us, as some of you are posting. But they jump out at us because they are the exceptions nowadays. As things progress we should expect that the serious front-line work will require

  • First: Some of the best stuff I ever worked on was entirely by me. For one thing, you don't have to get your point across to another person to know what you are trying to accomplish. Its actually very hard for lots of people to share a vision and work on it.

    Second: http://www.paulgraham.com/head... [paulgraham.com]
  • Well, not quite...I do have one other guy helping with a GUI admin tool that calls down into my system. But all the guts of my new, general-purpose data management system were written exclusively by me. I have a huge list of features yet to implement, so I could use a lot of help, but until someone steps up and wants to dive in with me, I am on my own. It is an incredibly ambitious product (think file system, relational database, key-value store, graph database, and distributed data management system all ro
  • There are definite advantages to a solo-programmer project.

    For starters, you can take shortcuts you couldn't take in a team, because there is a reason that you have all these coding styles and guidelines and templates and levels of abstraction and frameworks and all that other stuff, and the reason is "you are not the only person working on this project".

    Well, if you are a lot of these constraints disappear. I love to write code with a low amount of abstraction, because yes, I understand its advantages, but

    • What I have found is that, when I write code like I would for a team, I tend to re-use those modules, bits and pieces in many more projects; so the payoff is actually quite good in the long run. Furthermore, after a few months have passed I always regret when I have not documented those re-usable pieces well enough.
      • by Tom ( 822 )

        True to some extent. I didn't say forget all good practice.

        But, for example, for the game listed in my .sig I wrote a lot of very specific GIS code. Yes, I could have spent the additional time and conceptual work and written a generic "find object on map based on criteria" service and maybe it would be useful in some future project.

        But with what I've learnt doing it the way I did, I could write another task-specific piece of GIS code in half the time that the abstraction would cost me, with none of the over

  • Who else had never heard of this software before?
  • Good thing nobody told Notch [wikipedia.org] that the days of the solo programmer are over.
  • While it's not a program that an everyday user would use, the application DragonFrame is the work of a single developer. This application is used on most of the major stop motion animation movies (Boxtrolls, Shaun the Sheep, Frankenweenie, etc.). I think that one-developer applications require a very, very good (aka "rock star") developer who enjoys working on one project for a long time.
  • by quietwalker ( 969769 ) <pdughi@gmail.com> on Thursday August 27, 2015 @01:35PM (#50403987)

    - 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 [catb.org] 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 [wikipedia.org]. 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

  • Dwarf Fortress [google.com]!!!!!!!!!1!!!1eleventy!!!!!

    Here's a pretty cool article about Tarn Adams. His lifestyle sounds pretty similar to the guy in the cabin.

    http://www.nytimes.com/2011/07/24/magazine/the-brilliance-of-dwarf-fortress.html [nytimes.com]

  • that's mostly the work of one programmer, for instance luajit http://luajit.org/ [luajit.org] mostly the work of Mike Pall.

    He's transitioning to open sourced without him though.

    It's not perfect (for instance writing his own assembler instead of using a standard one for the interpreter makes debugging changes to the interpreter hard).

  • Its the "eat your own dogfood", what helps.

    A person has a problem, solves it with code and shares his program. He improves on the program, as he uses it and needs it, others benefit, too. He will be way more efficient and his product way more useful, than a hand full of programmiers, with some unclear specification, which needs to be worked on to check bulletpoints on a TODO list. They will do what they are told to, while he will do what he needs for his program to work fine. And if he sees that some idea w

Children begin by loving their parents. After a time they judge them. Rarely, if ever, do they forgive them. - Oscar Wilde

Working...