Several years ago, my friend and co-worker Rael wrote Blosxom. He had two goals: to write a very simple blogging platform and to write it in the fewest number of lines possible.
Rael's one of the best dabblers I've ever met; he's really good at finding an interesting new technology or pattern, writing something small but clever in it, and then moving on to something else. He asked me for Perl advice a couple of times with Blosxom, mostly to find golfing techniques to keep the software under 300 lines long.
That might not have been my most proud moment in writing maintainable software, but I appreciated it as an artistic exercise. (I've experimented in writing very short fiction, some of it 500 words or fewer and some of it only about 100 words long. It's difficult, but constraints help me make better decisions about what's really necessary.)
A couple of years later, Rael started a virtual private assistant as a service company, where his goal wasn't to write the least amount of code possible. His goal was to parse as much arbitrary human-generated text as possible to find useful information, such as times, dates, addresses, and contact information. (I'm sure his ultimate goal was to build a successful company with users who adored his software, and he did build up a group of users who adored his software.)
In my most recent client contract, the system had a few constraints:
- import as much data from the data sources as possible to achieve a 100% accuracy rating while throwing out no more than 1.5% of the data as unimportable
- process all user data change requests within 48 hours
- never violate data sharing rules while allowing those rules to change within 48 hours
- respect the native languages of users and their data (in other words, handle Unicode properly)
Blosxom uses plain text files with minimal formatting. It doesn't use a
database. The last time I looked at its searching mechanism, it shelled out to
grep. (When Rael first told me that, my reaction was "That's a
waste of... wait, that's very clever. Spawning a new process is relatively
cheap, and if you have the disk cache to spare on the searchable
files—and there aren't going to be multi-megabytes of those—then
it's a reasonable decision.") Blosxom itself is a single-file program you can
drop anywhere and run from a web server, from inetd, from an SSH session
manually, or even from cron or incron.
The client project uses multiple servers with PostgreSQL, a database change management system, a job queue, a copious test suite, an indexing system, a configuration management system, a geolocation service, and a reporting system. If something goes wrong, it should be easy to revert changes and redeploy the right thing.
My team spent a lot of time understanding what that system had to do, where the business wanted to go, how the software helped the business meet its goals, and what was likely to go wrong technically. Even though we didn't have the time or resources to do everything perfectly from the start (who does?), we took time to refine our processes and our code and our design as we and the business discovered more about what the whole system needed to do.
That's what I expect of any good team that's building something new. (If you're building the same software you've built many times before, good luck to you.)
One of the biggest risks we faced was getting Unicode right. If we hadn't been very careful (and knew what we were doing both with Unicode in general and Unicode in Perl in specific), we'd have wasted a lot of time and effort going the wrong direction and caused lots of bugs for users. Code written for dabbling doesn't have to go to the lengths we went to. (When was the last time a one-off script you wrote had to worry about Unicode normalization and collation order? Unless you're Tom Christiansen, Nick Patch, or a contributor to p5p, probably not that often.)
That all might explain my immediate reaction to Herd Thither, Me Hither. If you read that post as sincere (and I don't), you might take it as arguing that dabbling in new technologies and techniques is so important that you should stake your career on it.
That's probably overstating the argument, but then again, you've probably heard the bleating of the thunderous herds questioning why you're not using their most favorite, shiniest of all technologies. After all, Node.js's cooperative multitasking event-driven callback system is so fast and Haskell's type system makes it impossible to compile incorrect code and Clojure is basically Common Lisp for the 21st century and Python is the new BASIC and Rust will make D look like C++ and Ruby on Rails invented web programming. No, what you are using is so ooooooooold and outdated! Get with the times!
I wonder how many startups fail because they mistake what they can get out of dabbling in technology with developing for business. (That's a spectrum, by the way. A couple of days of exploring database deployment systems here and there paid off later by reducing the amount of work we had to do to support the system.) I've been doing this long enough that I no longer believe that technical superiority in and of itself guarantees success. Instead I believe that the ability to deliver working software that gets better over time and doesn't regress in quality, maintainability, and stability is a stronger indicator of success.
That is not a feature of technology newness. No, if success is an iceberg, the superficial technology choice is above the waterline. Unless you're aware of the rest of the constraints of the business, judging the development team's choices on that little part is silly and shortsighted.
