A second hazard arises in that, by looking for language-specific experience, this practice contains an implicit assumption that programming languages stand alone, with little relation to one another, and that learning a new one is a major undertaking.

These issues are two sides of the same coin, both flawed in their failure to recognize that, while programming languages are the means used to develop software, they are not the primary skills of software development.

The Right Tool For The Job

A commonly-used metaphor, and one which would have been appropriate to the points made in Why Do You Hire Programmers?, is that of a carpenter’s toolbox. “When you want to build a house, you look for a carpenter who builds houses, not a carpenter who has 5 years of experience using hammers and 2 years using nailguns with preference given to candidates who are also familiar with screwdrivers.”

While this metaphor does make a good point, that the craftsman’s skills go beyond the specific tools used and that you should trust him to use the right tool at the right time, I still have minor issues with it in that it preserves the misconception that each software development tool is fundamentally different from the others. Although there is some overlap between the skills of using hammers, nailguns, or screwdrivers, they are, by and large, three distinct activities. The skills of writing software in C, Java, or Smalltalk, on the other hand, overlap by much more than they differ.

Something A Little Less Prosaic

A much more apt metaphor would be to compare the programmer to the poet.

Skilled poets can write in many forms. A master of the sonnet can also be expected to competently produce ballads or limericks when called for and would likely be able to write a mean haiku with very little practice. The core skills of handling meter and rhyme or choosing the right words to paint a vivid image apply broadly across all poetic forms.

Similarly, a well-rounded developer is proficient in a variety of programming languages and can apply his core skills in logic and program structure to new languages with a minimum of difficulty. The techniques do vary from one language to another, with some placing more emphasis on one type of logic and others emphasizing structure more heavily, just as rhyme is everything to a limerick and irrelevant to a haiku, but this is generally a minor obstacle, if any at all.

Learning The Language

There is a common case where this falls apart, however: Programmers who only know a single language. Although it’s not inevitable, this often indicates someone who has solely learned that language without also learning the more general techniques of software development and how they apply beyond the one language.

The primary skills needed in software development are ways of thinking, of finding solutions for problems, and of structuring those solutions. They are not the vocabulary or syntax of particular programming languages. You will often be much better off with someone who has extensive experience with a wide range of technologies, but doesn’t know your particular language, than with someone who has extensive experience with your language, but has never used anything else.

1. A Correction To Last Tuesday’s Post

In Off the Record: Passwords, I recommended the use of SHA1 rather than MD5 hashes when storing passwords. Since then, I have encountered a persuasive argument in favor of abandoning both of them and using bcrypt instead, as it’s designed to be less time-efficient, thus dramatically reducing the number of potential passwords that a brute-force attack can attempt in a given amount of time.

As this can make your passwords much more secure against attackers while still keeping single-hash generation running at a reasonable pace, I have revised that post to recommend the use of bcrypt over SHA1 where available.

2. I’m Not Disappearing

New posts to this blog have slowed down substantially over the last couple weeks because the stockpile which I prepared prior to launching the blog have all been published and my new writing process, which I expect to work out much better in the long run, is taking longer than the old one to produce completed posts, ready to publish. If all goes as it appears that it will, the rate of new posts should pick up again by the end of next week if not sooner.

The First Rule of Program Optimization: Don’t do it.
The Second Rule of Program Optimization (for experts only!): Don’t do it yet.”
- Michael A. Jackson

If you spend much time with people who have any involvement with software development, you’re going to run across a conversation about optimizing software. Either the program is too big or too slow or too chatty on the network or too something and somebody wants to do a little optimization to improve on that.

It usually starts with the natural impulse of geeks to tinker with their systems, but project leads, marketing departments, and managers are often drawn in by the promise of a better product.

Should you find yourself in that position, contemplating either undertaking an optimization project or authorizing one, stop and consider what the proposed optimization is and how much it will actually improve things.

Optimizing Line-By-Line Is Rarely Worth It

Micro-optimizations are generally not worth the time it takes to make them. Shaving off a couple milliseconds from a function that only runs once is entirely pointless - it will produce no perceptible improvement, yet it comes at a potentially high cost in development time. Simple optimizations of this type are often already done automatically by the programming language behind the scenes anyhow, while more complex attempts may backfire.

The primary exception to this is when the code in question will be repeated many, many times in rapid succession. (Programmers often call this a “tight loop”.) If the code will run 10,000 times, then making it take a millisecond less each time will save a total of 10 seconds. If your user is sitting and waiting for the task to complete, that 10 seconds is an eternity. On the other hand, if it’s part of a 6-hour non-interactive process to close out your monthly books, the 10 seconds saved is meaningless despite the repetition.

Optimizing Algorithms Works Much Better

Several years ago, as I was just starting my programming career, I had a job doing data entry on a system which needed to run a check for duplicate records before posting completed tasks into its archival database. For performance reasons, it checked only those active records which were marked complete - and it still took nearly half an hour to run.

Eventually, the programmer who wrote the system left the company and I inherited his responsibilities for it. One of the first things I did was take a hard look at the duplicate checking code.

The duplicate check, as originally written, looked at every single record in the archival database for each active record that was being checked. Testing 10 active records for duplication against a 10,000-record archive database required 100,000 record-level comparisons. No wonder it was slow. It used an extremely inefficient algorithm.

Within a day, I had rewritten it with a better algorithm which only needed to make one pass over each database. With 1,000 active records and 10,000 archived, it could test every active record (not just the completed ones) with only around 11,000 record-level comparisons. It also used the databases more efficiently, bringing total run time down to roughly 15 seconds. Vastly improved performance, plus a more thorough check. A truly worthwhile optimization!

The Most Important Optimization

If I were to revise the original version of that duplicate check today, I could do even better. I’m confident that I could get it under 5 seconds and probably down into the 1-2 second range, while still running on the same, now horribly outdated, hardware and software.

Why are such extreme improvements possible? Because, at the time, I was able to devise a better algorithm than the original programmer had and because I now have several more years experience behind me than I did then.

If presented with my revised version, though, I would argue against further optimization of that code. Since it was just run once a week, it wouldn’t be worth the effort involved in bringing it down from 15 seconds to 5, maybe not even if it could get down to 1. Rewriting to eliminate the need to run the check at all might be worthwhile, but making the check faster would not.

The most important optimization is to optimize the skills and experience of your developers. Software development is not a commodity product. Getting someone with the skill to choose the right algorithms and the experience to know when an optimization wouldn’t produce sufficient improvement to justify the time invested will get you better results, in less time, and often for a lower overall cost.

Going open source can bring major benefits for your software and your company, but it can also invite disaster if you’re not familiar with both the concepts and the culture behind it. So let’s clear up some of the common misconceptions surrounding open source:

You Still Own Your Code

Whatever code you write (or pay someone to write for you as a “work for hire”) belongs to you, unless other arrangements are made. As the owner of the copyright on that code, you will never be legally bound by the terms of the code’s license, so you will still be able to use it in whatever non-open way you might desire.

Until you accept someone else’s patch.

If you release a FOSS project and I submit code for it, then I still own the copyright on my submission. By incorporating my changes into your project, you become bound by the project’s licensing terms because you no longer own the whole thing. The one exception to this is if I assign rights over my contribution to you above and beyond those in the FOSS license, most often through the use of a Contributor License Agreement.

You Can Sell FOSS

FOSS licenses place no restrictions on who can distribute the software covered by the license or how. Their restrictions apply to those who make changes to it. Depending on the license, anyone making modifications may be required to do such things as:

• make the source code available to anyone they distribute the software to
• provide attribution to the original author
• submit the changes back to the original author

 
Even if you are subject to the FOSS license, you can still sell or give the software to whoever you like. But they can also sell or give it to whoever they like, so the cost will tend to drop to zero rather quickly unless you can provide some additional value to encourage people to pay you for your version when they can get it free (and legally) from someone else.

One common way of doing this is to make use of a Contributor License Agreement, as mentioned above, which allows the original copyright holder to sell the project under a commercial license in addition to free distribution under a FOSS license.

Open Source Is Sharing

Open source is not a gimmick for getting programmers around the world to write a program for free which you can then turn around and sell. Unless the programmers gain some benefit from contributing to your project, they are unlikely to do so and, worse, you may get bad press in the FOSS community for trying to take advantage of them.

For this reason, FOSS licensing tends to work better for software which potential developers are likely to run on their own computers, not for the custom portions of an online service or other “unique” offering that’s intended to only run in one place.

I recently advised someone who wanted to set up a web-based service and sell subscriptions for access, but also to make it open source so that outside developers would contribute and improve on it. Although basing the commodity portions of such a system on existing FOSS projects works extremely well - that’s the heart of LAMP, after all - trying to present the service itself as FOSS would have gone quite poorly.

I explained that developers would have no reason to make free contributions to his for-pay service and, even if they did, they would need to set up their own working installations of the service to develop against, at which point they would be in a position to compete against him by offering the same service at no cost. This was a case for which FOSS was simply not well-suited to his objectives.

 
Have you considered using FOSS licenses for any of your projects or do you have further questions about FOSS which have not been addressed here?

It doesn’t much matter whether your project is the latest addition to the world’s surplus of data-entry systems or the next killer application which will revolutionize our lives, it’s going to involve a lot of common functions either way. Common functions which have already been implemented, dozens if not hundreds of times over. How much of that can and should you make use of?

There are existing frameworks which handle these common functions in broadly generic ways which can generally be customized to get an application based on them up and running relatively quickly and at a low cost. Most good frameworks also allow for plug-ins to expand on their base feature set similarly easily.

The other major option is to build a fully-custom application. This route is more expensive and takes longer to complete, but it ensures that you can get any desired features without being restricted by a framework’s underlying design or the availability of plug-ins. In the long term, it also can provide greater flexibility for your application if it is done correctly.

In some cases, it can be appropriate to combine both approaches, first building a framework-based prototype, then replacing it with a fully-custom final version. Due to the additional time and expense involved, this is generally only an option for large or business-defining projects, but the improved quality of the final result can justify those costs in such cases.

Characteristics of Framework-Based Development

• Faster initial implementation
• Lower cost
• Provides a solid, well-tested foundation for basic functionality
• Potentially more secure, due to lessons learned from attacks against other applications based on the same framework
• Many good frameworks are available for free under Open Source licenses, but some licenses may place requirements on how you use framework-based code
• Some frameworks include a “standard” look and feel, which is good for getting something that looks decent built quickly, but may ultimately limit design options

Characteristics of Fully-Custom Development

• Can produce whatever you desire
• Higher performance, as it will contain only what you need
• Potentially more secure, due to not being a well-known and thoroughly-analyzed target, provided the developer pays attention to security
• You will fully own the end result and can set your own licensing terms

 
What other advantages or disadvantages of either approach are there beyond what I’ve listed? Which do you tend to prefer?

If your answer is “to write code”, then think about it some more. I don’t know what your reason is, but I’m pretty sure that’s not it. Writing code is merely a means to an end, not an end in itself.

Do you want to create internal systems that keep your company running? Or are you looking to produce a product for sale to customers? Maybe you’re doing something else entirely?

I’ve seen this question presented from the marketing side a few times, usually in terms of “features” vs. “benefits”¹, but the same principle applies here. Just as you need to present a benefit to your customers when selling to them, you also need to consider the benefit that you want to obtain when you’re buying.

Probably the most common issues I see in this area are companies looking for a programmer who knows a specific language, or uses a specific database, or has experience with some other particular tool rather than focusing on the actual objective of the project: the functionality that they require.

This is not to say that you should never look for someone who can use specific tools. If you’re adding on to an existing Java application or if you have an existing team of Java developers that you mean to add to, then you’re probably going to want someone who can work with Java, and for good reason.

If you’re building something new, though, then you’re likely to be better served by finding someone with broad experience and the ability to create what you’re looking for, then asking him what the most appropriate tools would be. Since you’re hiring an expert, use his expertise. Any genuine expert should be able to clearly explain the advantages and disadvantages of different options to you in terms you can understand, no matter how technical or non-technical those terms may be.

Just don’t be surprised if the best option ends up not being the one that you would have chosen if you had started by picking the tool.

What have you hired programmers for in the past and what would you want to hire one for today?

¹ Basically, the concept is that you don’t want to sell the feature “our product has X”, but instead you should sell the benefit that “our product allows you to do Y”.

Looking back over it, I have to say that I really enjoyed this project. Not only was CyberPenguin’s owner great to work with and provided some of the best specs I’ve seen from any of my clients, but he was also always willing to discuss their content and to consider any suggestions I had for improving on his design.

Features

The case study itself provides fairly complete lists of the original functionality and what was added in the expansion project. The only thing that stands out as missing was the one part that I was least sure of being able to work in smoothly: Promotions.

The original spec called for an extremely flexible promotions structure, allowing operators to define various combinations of times of day, days of the week/month, minimum purchase amounts, etc. under which a user receives either a flat bonus amount or a percentage bonus to purchases of credit on his account.

Previous experience with calendars and scheduling software gave me a pretty good idea of how to handle the infrastructure behind the promotions functionality, and even to make it more flexible, allowing the criteria for promotion eligibility to be mixed and matched in any way desired rather than only the specified combinations. But I expected designing an interface to control this flexibility without overwhelming the user to be a somewhat more daunting task.

In the end, I was able to come up with a clear, simple way for users to specify a promotion to be, say, “Top up account by P10.00 and get 15% extra from midnight until 6:00 every 4th Monday, Wednesday, Friday.” And, yes, the interface is also able to describe the promotion details in English - that sentence was copied and pasted directly from it.

Technology

CyberPenguin runs on Ubuntu, which is derived from Debian GNU/Linux - my preferred operating system - so I was already very familiar with the server environment that I’d be working with. The workstations also run Ubuntu, under the control of DRBL (”Diskless Remote Boot in Linux”), which was new to me, but I was already familiar with other Linux-based thin client and diskless workstation setups, so it didn’t present any issues.

In addition to the Linux operating system, the rest of the application was built on Apache 2, MySQL 5, and Perl 5.8, making up a standard LAMP (Linux/Apache/MySQL/Perl) environment. In addition to LAMP for the web interface, the application makes use of Perl programs run as scheduled tasks (by cron) each minute and each day to handle the billing and accounting details.

But the latest, of course, is also the least stable. The most likely to have problems. The biggest risk.

Staying on top of the latest-and-greatest tech works out well on your own time, at least for those of us who like to tinker and don’t mind doing a bit of troubleshooting when the inevitable problems arise. As a professional, though, that’s rarely what’s best for clients.

On the other hand, stagnation isn’t good for anyone. Newer technology is needed to take advantage of the improved tools and techniques which are constantly being developed. Fifty-year-old mainframes running code in languages just as old are not a strong target for new development today, no matter how stable they may be.

This creates a constant tension between the desire to make use of the new and the need to retain the reliability of the not-so-new. It’s a tricky balance to get right and I see a lot of software developers who give in to the lure of the latest version, only to get burned when it crashes.

I even succumbed recently myself…

About two months ago, I was debating with myself whether to clean up the web application framework that has grown up out of several projects I’ve done and continue using it or to switch over to an existing framework. (I had previously looked at the major existing frameworks and found them wanting, but I make a habit of checking in on them once or twice a year to see if either they or I have changed enough that I’d want to use them.) As it turned out, I found that there was a new framework in town, created by a well-known developer with experience in such things, which avoided many of the pitfalls of the existing frameworks, so I decided to pitch in and help out with development and debugging.

It turned out to be much less complete than I had initially believed and, a month later - practically to the day - it pretty much disappeared.

During the time I was initially evaluating it, I had also been discussing a project with a potential new client and had mentioned it to her. She also thought it sounded great and was very interested in having me base her project on this new framework. Fortunately for me, the project ultimately didn’t happen, because, if I had committed myself to build it based on this shiny new framework, I would not have been able to do so without having to invest far more work than expected into completing the framework first.

How do you prefer to maintain a balance between the latest-and-greatest and the tried-and-true? Have you ever been bitten by this preference?

There was a recent post on Freelance Switch titled Questions & Answers: How to Describe What You Do on this general topic, so apparently it’s a problem which is shared by others with closer-to-mainstream specialties. Here are my answers to that article’s questions:

1. What kind of work do you do?

I write software to help clients manage information, technology, and/or business processes. Given the current state of the business world, this very frequently means writing web-based applications, but this does not mean I am a web developer. I primarily create software which sometimes happens to have a web interface, not websites which happen to have functionality behind them.

It can be a subtle (and, arguably, pedantic) distinction, but it means that I am equally comfortable setting up websites or creating software which just sits in the background, doing its thing (e.g., monitoring access logs or auditing user activity) with no human direction required and no user interface at all aside from writing to a log or sending out email notifications to tell you when it finds something amiss.

This distinction also means that web layout and graphic design are not really my specialty. If you’re building a website and know what you want it to do and what you want it to look like, I can make that happen, but, if you ask me to decide what it should look like, you’re likely to get something that looks fairly spartan (some might even say “boring”).

2. What makes you unique?

For starters, my preference to specialize in back-end processing rather than user interface design seems rather unique.

I’ve been developing software a long time - as I write this, I’ve been programming for 30 years total, 15 years professionally - and I have a breadth and depth of experience that few can match. I’ve worked in several different industries over the course of my career and learned not only how to write software, but also how to assess a situation and identify what software should be written. On top of that, I’ve worked some years in systems and network administration, giving a solid understanding of the environments in which software runs and how to ensure that it will do so reliably.

I also write software with a distinct eye towards future maintainability and expandability. I know that someone will have to fix or change it within the next year or two and I know that, more often than not, that someone will be me. This isn’t anything unique within the realm of traditional software development projects, but it is often sorely lacking in the “results now, don’t worry about tomorrow” world of far too many online projects.

3. What kind of clients do you have?

Mostly small-to-medium businesses. Organizations which are big enough to afford custom software development, but not large enough to have the available technical manpower to do such projects in-house.

I also do quite a bit of work with web designers who need an expert partner to help them out with projects that require heavier or more in-depth back-end development.

4. How much do you charge?

I normally prefer to bill hourly for my time, but I am willing to do fixed-bid projects if provided with a sufficiently-detailed specification of the project. Even with a good spec, though, I have found that hourly rates help to avoid potential conflicts over what work is or isn’t within the project scope.

Reduced rates are available for projects which are to be released under a Free/Open Source license or for which I will retain ownership of intellectual property rights after project completion.

5. What kind of business relationship will we have?

I primarily work independently and off-site, but will consider other arrangements provided that travel and other expenses are covered, including payment of my normal hourly rate for time spent in transit.

To avoid confusion caused by conflicting information, you will be expected to designate a single point of contact who will provide all direction on your project.

6. How do I pay you?

I am currently billing clients through Aurenav, LLC, as this allows me to focus on my clients’ projects without being distracted by invoicing, collections, or payroll issues. We will agree to a schedule for billing as part of the initial project contract and Aurenav will issue invoices according to that schedule. Payment on each invoice will be due within 30 days after it is issued.

7. How long have you been in business?

NomadNet, Inc. was founded in October, 2004.

8. Where are you located, and what are your hours?

I am a U.S. citizen currently resident in Lund, Sweden, but I typically work remotely, so you won’t have to worry about the expenses involved in getting me from Sweden to your site! On the contrary, the substantial majority of my clients have never met me in person, but instead have dealt with me entirely via email, phone, and/or Skype.

I am a bit of a night owl, but, thanks to the magic of time zones, this puts my most common working hours roughly in sync with standard business hours in the U.S.

I’ve seen some very good, very successful company blogs out there which have led me to the decision to start this one. The blogs I have in mind are those which visibly contribute to the success of the (small) business which runs them. These businesses have the common factor that the blog itself can serve to showcase the owner’s skills in that business - writers, business coaches, self-help gurus…

But I don’t do any of that. I write software. Writing software on the blog or blogging about how to write software would be a great way to contribute to the software development community, but it would have no relevance to anyone who might require my services. Conversely, a blog that was all about marketing would produce very little actual value, not to mention that it would be largely inauthentic of me to do so.

To resolve this, I’ve settled on creating a two-pronged blog. (All the pro bloggers who write about focusing on a single topic and never straying from one well-defined niche may now collectively gasp in dismay.) All posts will be categorized as either “Technical” or “Non-Technical”.

• “Technical” posts will be those which directly relate to the actual process of crafting software. The first few in this category will be design- and usability-focused, but coding techniques and the like will appear there, too.
• “Non-Technical” posts will cover anything else.

Feel free to subscribe to only one category’s RSS feed if the other doesn’t interest you. It won’t bother me in the least. Honest.

That still doesn’t address the issue of showcasing my skills on the blog, though.

I’ve decided that the way to accomplish that is to make the blog itself a demonstration of my skills by writing my own blog software, to be known (somewhat unimaginatively) as NomadNet::Blog. It’s not going quickly, as I don’t have that much free working time to do it in, so I’ve decided to start out with using WordPress rather than waiting until NN::Blog is ready to face the world. Going this route will also pretty much force me to write an import tool which will convert a WordPress blog’s data into something usable by NN::Blog; I expect that having this capability will greatly increase the odds of anyone other than me using it.

So that’s where we’re starting from. Stick around and I hope you enjoy your stay.
 
 
 
P.S. Getting this blog to match the look of the rest of my site involved a bit of ad hoc tweaking to WordPress beyond simply editing the base Sandbox theme. If you happen to notice any dark corners of the blog which don’t look quite right, please contact me and let me know so that I can get them cleaned up.