Building my business

The past week’s activity has been fun, but of course the trick is to turn it into income. I now have the beginning of a business strategy.

Things have changed a lot in the independent software contracting business since I was last in it in 2004. In some ways it’s gotten tougher, but it’s also possible to reach more people. I’ve tried some things that haven’t worked too well. Dice is great if you’re looking for regular employment, but it’s a waste of time if you’re looking for clients. LinkedIn may prove useful, but it’s no magic bullet.

The key is to have a specialty and to apply it flexibly. I can reach lots of people; so can everyone else. Making the new world order work requires reaching the right people in an intelligent way. Agencies, at least the ones that have been calling me, just try to hammer as many pegs into as many holes as possible.

I have certain specialties and I’m known in certain communities. These are strengths if I can reach the appropriate people. I’m doing that already in some ways, with my File Formats Blog and professional contacts on Twitter. I’m planning to attend some conferences. Beyond that, there’s another step which I hope will make a significant difference.

I’m now primarily responsible for the JHOVE open source project, and have put updates into a beta version in the past week. I’ve also been working on a project relating to linked data and file format registries. So far this has been interesting mostly for its negative results, but there’s enough to it to make available.

I like to write code, and giving it away, if done right, is a form of advertising as well as building my skills. These projects will be clean but limited demonstrations of what I have to offer, of some use in themselves but open to expansion, with my contact information clearly on them. The package won’t be just the software, but an explanation of what problem I’m attacking; it won’t have just a link to my website, but a reason to read it. Since this software is most useful to the people who would want my skills, it’s advertising with free distribution. Not free advertising, of course, but I’ll be paying for it in effort rather than money.

I’m considering moving from its current cheap hosting (it’s sharing the rent with right now) to a virtual server, so that I can put demonstrable Web software up. It’s remarkable how little a virtual server costs per month.

It’s an adventure, and if it works out I’m finally doing things I really want to do.

The anti-Agile manifesto

This post is a big shift from what I’ve been writing here before, but it’s my blog and I can do that if I want. :) Besides, I’m sure there are regular readers who are interested in this topic.

Lately I’ve been exposed more than I like to something called “Agile Development.” It’s a software development methodology which codifies the bad habits of many programmers. Its founding document is the “Agile Manifesto.” Its main tenets are brief:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Expressions like the last one nearly always mean “We don’t care about the items on the right.”

The first point is meaningless. Individuals are the ones who do the work. Processes are how they do it. They aren’t commensurable. Placing either one “over” the other just doesn’t mean anything. And really, today’s world is much too interactive for effective software development. Programmers need to be able to concentrate, not to be interrupted every five minutes with e-mail and instant messages and constantly shifted from one task to another.

The second disparages documentation. If you’ve ever tried to work with uncommented, undocumented code, you know what a pain it is. Working software that subsequent programmers can’t figure out doesn’t stay working.

“Customer collaboration over contract negotiation” actually does make sense, and it’s what attracts people to agile development. But watch out for everything else that comes with this package deal.

A plan for developing software should include allocating time and resources for responding to change, but just reacting to changes can’t replace planning.

The Agile line depends heavily on a straw man. If you don’t use Agile, its proponents tell us, you have to use Waterfall. Then we must have been using Waterfall all our lives, being ignorant of the glory of Agile. What? You’d never heard of it till the Agile people told you? Neither had I. Wikipedia tells us (as of this writing, the always-necessary caveat with that source) that “[s]ince no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.[citation needed]” Adopted by whom? Citation needed, indeed. In the Waterfall approach, you gather all requirements, then you do the design, then you implement it, then you verify it, and finally you go into maintenance. There is no overlap; one stage must finish before the next starts. This seems to mean you don’t do any prototyping during the first two stages, and you don’t test the code until it’s completely written. You always do development this way, don’t you? No? I don’t either. Maybe those people doing secret government contracts are the ones who do. That would help explain why they cost so much.

Less formally, Agile means things like putting the emphasis on getting something that demonstrates some functionality over sustainable design. Agile advocates tend to say that planning for future refactoring of code is a waste of time. If you have to change data bases down the line, you’ll just throw the whole thing out and start over anyway. If the code was written on those assumptions, that will be all you can do.

In my long experience in software development, certain things are consistent, and they aren’t Waterfall. Managers want software rushed out, often on the basis of inadequate specifications. They want something now, and they’ll worry later about having something maintainable. Developers don’t like to comment their code and don’t particularly like to take the trouble of planning for flexibility from the start.

I do have to grant the strength of the third point again, the one that carries all the nonsense along with it. Software managers like to keep programmers in isolation. They’re afraid of what we’ll say to the users: things like “That’s a bad idea” or “It’ll take a long time to implement that for very little benefit” or “why not do this instead?” There’s a common saying among programmers: “I must be a mushroom. They keep me in the dark and feed me bullshit.” Grabbing on to an argument for actually talking to the users, and seeing their bad habits confirmed, they’re naturally attracted to Agile.

But we’re also the programmers who have to maintain the previous developers’ uncommented, unplanned spaghetti code, and that isn’t fun. We’re the ones who’ll have to deal with unexpected changes later on, and that will be hard if we wrote novella-sized subroutines that do everything. We should be pushing the idea of communicating with users without swallowing the whole package of bad design practices. Maybe that could have its own buzzword. Sensible Development, anyone?