When you move on to your next challenge how will those that inherit your code think of you? Noble or notorious, innovator or insane? This is a question that all developers should ask themselves frequently; though too few ever do. You should always write with the assumption that someday a new developer will take over your code, and they will question every decision and assumption you’ve made. When this happens, what will they think of you?

Perhaps I’m more aware of this because I maintain an internally developed shared library that my company uses in every application; but regardless of the scope of the project you should always assume that someday you will hand the project off. Many developers think little about what happens to their code after it passes on to another; what other developers will have to deal with, or how their efforts will be perceived.

When I’m training a new developer there are a few points I try to reinforce as much as possible:

1. Code is only good if other developers can work on it without extensive training. If it takes days or weeks of introduction to get a new developer up to speed, then you’ve done something wrong¹.
2. Clever solutions are no better than an ugly hack if it’s not clear what you are doing. If the code isn’t clear then it’s not maintainable, if it’s not maintainable then it’s junk.
3. Assume you’ll be hit by a bus. Always write code with the assumption that you won’t have the opportunity to cleanly pass the code off to a new maintainer. Never assume that you’ll have time to come back and clean things up later.
4. Always perform design reviews, no matter the size of the project². Once you have a design in mind, talk it through with a at least two other developers. Just because you think it’s clean and clear doesn’t mean that others will see it that way as well.
5. Be consistent, always. I’ve seen more projects ruined by people doing things “their way” than anything else. Match style and design when working on an existing project. Be careful when adding new techniques, technologies, or methodologies to an existing project; unless you are willing to update the entire code-base, you can easily create a minefield without realizing it.

If you want your work to be seen positively after you move on, start thinking about your heirs today. The opinion they have of you will be almost entirely based on what they see in your code – not the stories or memories left behind.

¹ – There are always exceptions; these are generalized guidelines, not hard and fast rules.
² – This includes “throw away” projects, many projects that are intended to have a short life end up living far longer than intended. This is the most likely place that your heirs will find code that makes them question the quality of your work.

I’ve been a fan of bbPress for quite some time; I’ve even contributed code to the project. For those that aren’t familiar with it, bbPress is an open-source forum system written in PHP. It’s fast, lightweight, easy to install and even easier to use. It also scales, quite well.

bbPress was originally written to power the support forums WordPress.org, which get quite a bit of traffic. Later, it was released as a separate project. While it doesn’t have nearly the feature set found in more popular systems such as vBulletin or phpBB; it makes up for it in simplicity. It’s designed to be conversation-centered, where the clear focus is on what people are saying, not the bells and whistles provided by the software.

I’ve used it for a couple sites and couldn’t be more pleased; though now I fear the end may be near.

Automattic, the company behind Wordpress.com (and ListPress.com) has committed to supporting the project; though primarily in context to its role in the WordPress world. bbPress as a separate product has so much potential, though it seems Automattic has little interest in this; instead the interest seems to be in making bbPress just another add-on for WordPress.

At one point there was a lot of excitement and interest surrounding bbPress, though for a project like this to succeed you need input from the community, you need an open and fast paced development process. Unfortunately for bbPress, it had no such process. There were people who had the skill, time, and interest to lead the project and make it a success; but they were pushed away and the project was allowed to stagnate.

Today, there is some activity going on, and I’m glad to see that it won’t fade away completely; though I see little chance that it will live up to what it could have been. I have a lot of respect for Matt and Automattic; they’re very successful and build great products; but they could have done so much more.

bbPress will go on I’m sure; though I believe only as a shadow of what it could have been. Though maybe Matt will prove me wrong, I certainly hope so.

When it comes to small business project management, Basecamp by 37signals has been the king of the hill for some time. Now though, there is an exciting new player in the field: Open Atrium. It’s a Drupal based open source project management system somewhat like Basecamp, though with many more features.

Open Atrium is new on the scene, with beta 1 being released just 4 days ago – though it’s already rather polished and seems to work well. While there are some hiccups with the installer and a disappointing lack of documentation, it’s still very easy to install and takes only a few minutes to get running.

It has all the major features that you would expect, plus a few extras such as a twitter-like shoutbox system. Here are the highlights:

• Blogging
• Calendar
• Dashboard
• Document Storage
• Task Management

Being open source and self-hosted adds some nice benefits; unlimited customization, full control of your data, and my favorite: can be installed on a non-public web server. Having you project management system sit behind a VPN is a great way to avoid data leaks and embarrassments.

I’m still debating which is best, Basecamp or Open Atrium – but if you want to save some money, Open Atrium is worth looking into.

I’ve been working on a project recently that uses avatars, while planning out this specific feature it occurred to me – why should we re-invent the wheel? There’s already at least one service that specializes in doing it right: Gravatar.

While building something as simple as avatar support takes a relatively small amount of time, when working against a tight deadline or a tight budget every minute counts. In the world of an ISV (especially a young one) the balance of user satisfaction and development time is critical. Using a service such as Gravatar is a great way to give the users what they want with minimal impact to the timeline.

With a super-simple implementation we were able to get it running within a few minutes – compare that to at least a few hours to build a custom system. Plus, reduced server load as we aren’t hosting the images and a cleaner, simpler interface as it’s one less option the user has to look through.

Over the next few weeks (and months) I’ll be posting a series of articles on the tools and services that start-ups can use to make their business both more efficient and more profitable. This is aimed at ISVs (both micro and close to micro) though most of this should apply to any technology startup.

When you are starting a business, there are many important considerations with anything you use, here are the keys points I’ll be looking at:

• Expense – This is probably the top requirement. Budgets tend to be quite limited, and there are always too many demands on what budget is available.
• Effectiveness – It has to work; when running an ISV you simply don’t have time to waste. There is software to build and a business to run – there’s no time to waste on things that don’t work.
• Power – Just because you’re running a small business, doesn’t mean you have to miss out on the power and features available to significantly larger business.
• Flexibility – ISVs have a great benefit over larger businesses; agility. The very nature of smaller businesses give them a great ability to adapt to change – and the tools and services they use should be just as flexible.

There are many great resources out there – the challenge is digging through the clutter.

Posts so far:

• Start-up Tools: Microsoft BizSpark
• Start-up Tools: Open Atrium

I normally don’t write posts just to point out an article by another author, but the latest by Jeff Atwood is a must read:

Hardware is Cheap, Programmers are Expensive

I point this out because this is something I’ve been fighting recently. It’s easier for management to tell the development team to fix a performance issue than to request money for the new hardware that’s needed.

In the long run it would be much cheaper to just throw more hardware at it – though that requires higher level approval. Whereas assigning a couple developers doesn’t require going nearly as high.