All posts under /Home/Reflections
For some time now I've been thinking about the The Web We Lost. I'm certainly not the first person to be commenting on this epoch: Anil Dash has some very cogent points on the matter as have others. The lost web doesn't only refer to the infrastructure or systems that enabled "open computing" (the idea that anyone could exercise the power of content creation or effect control over their own systems and data), but also the missing building blocks that should have been but weren't.
Instead of walled off corporate gardens like Facebook, Google, Twitter or any of the other behemoths that offer little but take much, wikis are probably some of the best examples of how the Internet should have been. Technologies like Gopher, though not entirely dead, were left in the dust in our pursuit of flash, convenience and the almighty dollar. Somewhere along the way we lost the ability to exert our will over the technology we use and sadly, our lack of interest and attention have resulted people using Facebook as a news source of all things. Read this interview with Noam Chomsky if you want to understand just how influential a "news source" can be.
The blame for the current state of the web can perhaps be laid at the feet of high school educators. I know this sounds absurd at first, so you'll have to bear with me for a minute while I explain. The high school years are crucial for young people who are beginning to develop a "world view" that moves beyond being merely passive actors on the global stage. With electronic technology the ever pervasive medium for facilitating communication, forming communities and consuming news, it is more important than ever that young people be taught how to navigate such technology and understand the consequences involved. How much more difficult would it be for tyrants, governments and CEOs to effect their plans if citizens were more enlightened and aware of how technology can be used against them, and how they can empower change by being in control of their technology. Sadly, few courses are available for young people during these formative years and even fewer are the educators who really understand what is at stake.
All is not lost, though. The first steps to asserting your control over the web can be taken by learning how to self-publish.
How does one self-publish?
You can send email. For anything more complicated than "please pick up some eggs", it's still the best way to communicate one-on-one or one-to-many.
You can create free, fast web pages through txti.es. A txti page uses Markdown to format the page. It's not difficult to use.
You can start a wiki with some free software like TiddlyWiki or WikidPad.
You can start a blog with Micro.blog or any of the other free blogging platforms.
The next steps might be Beyond the Web.
In the nearly five years since I changed careers to become a full-time firefighter I have kept my distance from developing software of any consequence. To be honest, I had lost my desire to sit at a keyboard and relished the chance to spend my time in other ways. Sure, I've made the switch from Linux to FreeBSD, written a few scripts here and there, created a wiki for firefighters and even dabbled in automated stock market analysis for my own interest but I have otherwise turned down for-profit programming gigs in favour of freedom to spend my time elsewhere.
Although my day job as a firefighter has little to do with software development my prior experience building software has come in handy from time to time. In late 2015 I began working on a couple of small programs to replace a shared spreadsheet used by firefighters to record productivity metrics. Using the old system, only one person could enter data at any given time and it was too easy to accidentally wipe-out changes made by others. To solve this problem, I created two small programs using VBScript and HTML Applications as the foundation. Both of these scripts present simple, domain-specific interfaces that make sense to the users and hide the relative complexity of Excel by recording data in spreadsheet files in the background. One script allows users to record productivity information and the other generates a report from this information for use by management-level personnel. The program went live after about 80 or 90 hours of design, development, end-user documentation and testing. It solves all of the problems of the previous system, is simple to maintain and runs with minimal dependencies. It was distributed by placing a link on our intranet that opens a folder where the relevant scripts can be double-clicked and launched. Since it launched I have received a great deal of feedback that indicated that users were happy with the new system and that it ultimately made their job easier.
Recently I began to develop another piece of software. This time we're dealing with the management of annual hose testing information. The problem is significantly more complicated than the previous project which merely dealt with the recording and reporting of numbers for different categories but I'm hopeful that goals of this project will have similar positive results for the fire department.
As I found myself back at the keyboard for the second time I have begun to think about the considerations that will ensure that the current project is as much of a success as the last one. Here are my thoughts, in no particular order, about what makes "good software."