Stikis

When I think of stikis, I think of little squares that you can move around and type into and being able to zoom around the page. Writing the code to do these things was lot of work, but I’m beginning to appreciate that it’s only a small proportion of the total amount of work required to keep a site like this running. There are lots of other less glamorous things, such as writing help pages, making sure software is kept up to date, deleting spam comments from the wiki, responding to emails, and writing blog posts. In this way, stikis is sort of like an iceberg. There’s the small visible part out the top and the big hidden part beneath.

Models of the software development process often focus on the steps involved and how they relate to one another in a sequence. For example, the famous waterfall model represents software design as happening in stages from requirements gathering, to specification, to implementation, testing, integration and maintenance. Another well known model, the spiral model, while more sophisticated (giving more attention to iterative aspects of software development) is still constructed around the idea of stages and progression.

Models like this are especially useful as resources for project management and planning because they highlight dependencies between stages thereby allowing project managers to assign and coordinate organisational responsibilities. However, in a single developer project - like stikis - these organisational aspects are less important. What instead becomes difficult is maintaining a balance between all the different tasks that are required. This is especially so in a web-application context, where development, testing, maintenance and support are running alongside an already deployed application. In this case, I think it might be more useful to think of software development as being like an iceberg, rather than a waterfall or spiral.

The thing about icebergs is that they need to maintain a balance between the small visible part and the larger hidden part. If they don’t then the iceberg’s going to tip over (and the penguins won’t be happy). This is where thinking about your development work as an iceberg gets useful. The fun parts above the water are always calling for your attention, but if you spend all your time working there, you’ll eventually end up with help pages that are out of date, tests that don’t test the right things and spam-filled forums.

I’m not sure of the exact numbers, but if we assume that 86% of the average iceberg is beneath the water and 14% above - then that means for every hour you spend working on new features, you need to spend 6 working on the other stuff. Conveniently for the single developer, this means that you can plan your week of spare-time-development something like:

• mon: interaction design
• tue: write tests (software design)
• wed: develop
• thu: documentation
• fri: blog
• sat: deploy
• sun: server maintenance & review usage

…or some other order - provided enough time is spent on each of the activities. (Support emails should be answered as soon as possible.)

Does this seem sane?

While I was I writing this post, the list of people that are signed up to stikis has gone from being mostly people I know, to mostly people I don’t know. That’s kind of a weird feeling. It’s mainly thanks to myopenid.com, who listed stikis on their directory last week.

Getting people coming to the site from the wild meant that the old sign in page (three bare forms with no explanatory text) was totally inadequate. So after months of embarassment every time I log in to stikis.com, I’ve finally gotten to the task of creating a proper landing page for the site. As usual, the landing page is just a step in the right direction rather than a fait accompli. But I think it has some nice features all the same. Here’s a screenshot.

The main gimmick of the landing page is that it’s got some stikis at the top that describe what the site is. You can click on these, move them, and resize them. Below them, I’ve rearranged the login and sign-up forms into a two-column layout.

It’s obviously a risk putting all that javascript up-front on the landing page. It increases the load time and there’s the risk that an error will render the page unusable. However, if it works, I think it’s a very effective way of communicating not just the features of the site, but also something of the quality of the interaction (and whether it will work on their browser).

There’s also something about playing with those little blurbs that helps cut through the cheesiness of them. If I were to read “Space for your ideas” on a website I’d think “gimme a break” but when you start playing around with them hopefully you can kind of see what that cheesy marketing speak is trying to say.

Another change which is fairly minor is the addition of a footer with the following request; “Please tell me how to make stikis better.” I’m really hoping I’ll get some feedback from users as a result of this and I think it’s important to let people see who I am and understand that the site is a one-person project.