Stories about Software



Back Story

Recently, I set up a media wiki installation. The surrounding requirements were such that I was forced to use a Windows 2003 server instead of Linux, which would have been my preference, but hey, when life gives you lemons, turn the lemon into a WAMP stack. And that’s just what I did. The installs for Apache, PHP, and MySQL went quite smoothly in spite of having to use Windows, and I was up and running with Mediawiki in no time. As an aside, I should note that I tried out a handful of “all in one” WAMP stack offerings and none of them really seemed to work very well. Doing it by hand actually turned out to suit my needs best.

I should also point out that I don’t really have anything against Windows OS at all–I just prefer Linux when it comes to servers. Less overhead, easier security, and more bang for your RAM/processor buck. And I also prefer not to have constraints imposed on me, but c’est la vie.

So with my new Mediawiki install in place on the WAMP stack, I was thinking about backup schemes. I downloaded and installed MySQL Administrator GUI tool (now EOL’ed in favor of MySQL Workbench, which I think needs to get a little more mature and iron out some kinks) and configured an automated weekly backup of the Mediawiki database. Of course, that’s only half the story with Mediawiki–you also need to back up changes you’ve made to the PHP files themselves, where applicable, and any files and images uploaded to the wiki.

My Old Friend, Subversion

For this backup, I decided to go with subversion, reasoning that Tortoise would make it easy for me to see when I had modified files or when people had uploaded things to the wiki. I’d commit periodically, perhaps in conjunction with my automated DB backups, and this would give me a way to completely recreate my Mediawiki install at any point. If I hosted a subversion server on my server machine, I could commit weekly to it locally, and then update from another machine to ensure that I had an offline copy at all times. Perhaps not the most sophisticated backup scheme in the world, but it would get the job done, and I’d have a subversion server as a bonus.

With a New Twist

So when I went to download a subversion install for my Windows server, I stumbled on VisualSVN. Curious, I read about it a bit and decided to give it a whirl. I downloaded the MSI and installed it locally. I could not have been more pleased with the results. I use a subversion server at home on a Fedora server, and when I set that up, I had to mess around with configuring Apache and do something or another with security certificates, if I recall correctly. It’s been a few years, but I remember it being something of a hassle.

VisualSVN ran me through a wizard, and I was up and running with a password protected, directory-level-configurable subversion server that used secure HTTP. It was literally that simple. Already pleased, I saw that there were two main modes of security–subversion and Active Directory. Subversion was default, and it required me to create users and assign them passwords.

At first, this is what I went with, but I was a little put off to learn that the users wouldn’t be able to change the initial passwords that I assigned them. I was, however, pleased to find that I could control with the finest granularity which users had access to which directories. So I set off in search of a scheme that would allow users to change their own passwords. I switched to the Active Directory setting and started to play with it. What I discovered was that it was a snap to setup users needing to login with their own Windows Domain credentials.

So, viola! I didn’t need to create accounts or assign passwords and ask users to change them. They were already synced up with their own logins. From here, I was able to keep the same granularity by adding users in from the domain rather than manually. As setups went, I had a pretty slick one in about fifteen minutes for subversion.

The only drawback, as I see it, is that users can cache their domain passwords locally so as not to have to supply credentials for every SVN operation that they do. The drawback isn’t that they aren’t queried each time, which would be annoying, but rather that they can store their passwords. Of course, the passwords are encrypted by virtue of the HTTPS protocol, so this is really a small nitpick, and I really see no good way around it short of annoying the repository’s users. Not to mention, other applications like MS Outlook and web browsers offer the same kind of local storage, so it isn’t as if I’m doing something unprecedented.

So, if you get a chance, I highly recommend checking out this tool. The version I installed is a free one, though there is a fairly reasonable enterprise edition that gets you some more bells and whistles (if I recall correctly, it uses your current login credentials instead of a user/pass challenge). I might go to that later if the SVN install gains some traction and users like it.


Software Craftsmanship and the Art of Software


I’m a member of the LinkedIn group “Software Craftsmanship.” I’m not an active member, but I do like perusing the discussion topics. Recently, I read through this discussion on whether software is more of an “art” or a “craft.” This set me to musing a bit, so I thought I would post about it here.

Is Software a Craft?

A lot of discussion in the group seemed to involve meta-discussion about semantics. “What is a craft?” “What is art?” While this may seem like an academic exercise in splitting hairs, I feel that metaphors for process, software design, and pretty much everything that you might want to do are quite important–so much so that I made an earlier blog post about metaphors for software design in which I discussed this subject at length.

On the idea of whether or not software design and development is a craft, I think there are two operating definitions that potentially cloud the issue. One seems to be the dictionary definition that one might expect, where “craft” is something along the lines of a trade or some occupation that requires skill at something. Using this definition, software design is trivially a craft. There’s not a lot of room for argument there. I think the notion of software as a craft becomes more interesting in the context in which it’s adopted by the Software Craftsmanship movement–the idea of medieval craftsmanship in which there was some notion of apprenticeship being required before the aspiring tradesman could venture out into the world on his own. Perhaps naming the movement “Software Guildsmanship” would be more clear, if a little weird.

Software Guilds

At any rate, the guild metaphor is very good for expressing the feeling that there ought to be some standard met by anyone who wishes to develop software. At first blush, we might think that an undergraduate degree in Computer Science is the standard, but there are still plenty of self-taught programmers and people who attend trade school or else somehow transition into software development. And, furthermore, a computer science degree often gives more of a theoretical background as opposed to teaching would-be programmers the ropes of actual software development. In some very real sense, the CS degree is akin to taking courses in E&M physics to become an electrician. When you get done, you can give an excellent treatise on magnetic flux, but you may have no idea whether it’s really necessary to use conduit when connecting a switch to a junction box.

So, at present, there really is no modern-guild equivalent for software development. They do exist in other professions, though. The aforementioned electricians, lawyers, doctors, and certain types of engineers all belong to the modern equivalent of a guild, whether it’s a union with its political clout or some kind of licensing body (generally the functional equivalent of a union, particularly in the case of lawyers). The principles persist–some required standard for admittance (medical board exams), some notion of standardized pricing of services (union labor), repercussions for not cooperating with the explicit or implicit bylaws of the group (being “disbarred”), etc. The question is whether or not this should apply to software development, and I think that most members of the Software Craftsmanship school of thinking believe that it should.

Me, I’m not so sure. I think the intentions are sound, but the ramifications are potentially odd. Anyone who has looked at a particularly poorly designed piece of software probably, in that moment, would love some standardization of what is acceptable and to have the author of the offending code stripped of some kind of software development credentials. But that sort of overlooks all of the modes in which software is developed.

Lawyers, doctors, electricians, etc. are all sanctioned–“guilded,” if you will–because they provide some kind of external service — they act as agents for individuals or organizations. Software development has a wider range of use. Often we write software and sell it as a product, but sometimes we write software for fun, for friends, as a quick and dirty way to automate something, for posterity (FOSS), or internally for an organization who is both “purchaser” and “vendor” in one swoop. Contrast this with the guilded positions that I’ve been mentioning. People don’t practice law at home to make reading spreadsheets easier. People don’t practice medicine for fun. And some of these guilders could do what they do for free or internally for a company, but even if they did, they would act as an agent for someone who can be legitimately harmed by malpractice. If a pro-bono lawyer messes up, his client can still land in jail. If an incompetent electrician wires up his brother’s apartment, the apartment building can burn down.

With software, it’s a lot murkier. There are many scenarios in which software cannot have any negative ramifications for anyone involved. There is no implied responsibility simply because someone has created some piece of software, whereas there is implied responsibility in the guilded professions.

So Is the Metaphor Valid?

All that said, I think the idea of Software Craftsmanship is a valid one. But I think it’s important to remember that this is an imperfect metaphor. I like the idea of an opt-in software guild (i.e. potentially the Software Craftsmanship movement) in which members agree to practice due diligence with regard to producing good quality software. I even like the idea of apprenticeship, and I think that members of the movement ought to take on ‘apprentices’ (in a strictly voluntary interaction). This group of people ought to be software professionals and aspiring software professionals with the common goal of standardizing good practices and raising the bar of software design in general. But I think a slightly different metaphor is in order. After all, what I’m describing is less like a guild and more like a professional association.

Is Software Development an Art?

To this question, I have to give an opinion of a definite “no.” People like to have their work appreciated. If you spend a long enough time pouring your heart and soul into something, you will want to view it in an artistic context because you’ll want others to appreciate what you’ve done and see beauty in your work. But most forms of art, in the commonly accepted sense, are created for pure aesthetic value. Your software is only art if you never compile it, opting instead to print out the source code, frame it, and hang it over your mantle.

Make no mistake–at its core, software is a tool and a means to an end. You may be particularly efficient in creating these tools, but that doesn’t mean that you’re creating art. You’re automating processes and doing a good job of it. But nobody buys software for aesthetics. The only exception I can think of is software whose purpose is to look pretty or aesthetically appealing, such as video games or fractals. But the art there is in the rendering and not the software plumbing.

To refer to software development as an art, in my opinion, undercuts the value of the activity by implying that the goal is aesthetics rather than utility. We’re not selling people software because they want to own something that has the loosest component coupling they’ve ever seen or because it has no global state–we’re selling people software because they want to do their taxes, check their email, or look for reruns of sitcoms on the internet.

Software development is an art only inasmuch as everything is an art. If I hear developers talking about being good at their art, this to me is akin to mechanics talking about the ‘art’ of fixing cars or engineers talking about the ‘art’ of building planes. It’s only art in the vernacular sense of “This person is so much better at this activity than other people that I’m going to use the term ‘art’ to convey my appreciation.” I would argue that there is a certain danger in taking it any further than that. Specifically, the software designer who believes that his work is art is likely to lose sight of the fact that, without a need, there is no use for his work, and the aesthetics of filling that need do not trump the actual filling of the need. Nestcape might have been destined to be the most beautifully crafted piece of software in the history of mankind, but Internet Explorer still commands the market because its developers were interested in making money, not selling tickets to the grand unveiling.