Software is a Risky Business
It seems to me that if there were any logic to our language, trust would be a four letter word.
– Joel Goodson
Starting a relationship with a software development firm can be intimidating, and frankly somewhat risky. Clients need developers to understand and implement their vision quickly and thoroughly, use budget carefully, follow best practices in areas that are hard to verify, and respect confidentiality. This requires a lot of trust, and trust can be hard to come by in any new relationship.
What may be less obvious is that trust is required in both directions. Developers rely on clients to communicate their needs clearly and honestly. They need to have releases thoroughly examined, candid feedback provided, and financial matters handled responsibly. This extends beyond paying the bills; engaging in a software project requires careful planning to ensure that the project doesn’t end up underfunded and incomplete.
So how can a prospective client know that they’re making a reasonable choice in hiring a particular firm, and also that they’re prepared to hold up their end of the bargain? What follows is an overview of what one can expect to encounter in a successful collaborative development relationship.
1. Successful Development Relationships are Interactive
For good ideas and true innovation, you need human interaction, conflict, argument, debate.
– Margaret Heffernan
A good relationship features each party bringing their expertise to the table on a regular basis. Frequent communication is obviously a big part of this. Clients and developers should be speaking with one other each week. There’s something unique about people talking in real-time; whether face-to-face, in a video conference, or over the phone:
-
It can bring surprising assumptions to light. I’ve learned about usage patterns, such as a reliance on (or avoidance of) keyboard shortcuts. I’ve known clients who always rebooted their machine after installing drivers, even when that wasn’t required. These insights have improved product design and made it possible to reproduce subtle bugs.
-
It can quickly clarify details that might otherwise require lengthy email threads.
-
Most importantly it strengthens the relationship, and this is the key to almost all successful software collaborations. If the relationship is solid, it’s easier to get through the inevitable challenges gracefully. Getting to know one another beyond the immediate context of the project needs can be part of this; investing time and energy in communication is ultimately an investment in the success of the project.
How often should clients and developers meet? Facetious though it may sound, the right answer is, “As often as is necessary”. This is not an area to try to scale back in order to save some money. If a meeting is the best place to communicate requirements, ask questions, obtain reassurance or clarification, that meeting is valuable. On the other hand, when meetings are happening because of a lack of trust, there’s a deeper problem that needs to be dealt with directly. When a client loses confidence in a developer the instinct is often to request daily meetings to ensure work is progressing appropriately. While ramping up communication during times of stress can be useful, it can also make sense to step back and address the larger concerns through frank discussions and perhaps re-evaluating the overall project status.
Interactivity is about more than just the mechanics of communication, however. It’s an acknowledgment that the development partnership is pairing experts in building software with experts in a different domain, and that both perspectives are critical. There’s a mutual respect that results from that awareness, and a free flow of ideas. During my tenure as a software developer I’ve learned a tremendous amount from clients; from pro-audio to international fashion design. In turn I’ve been able to communicate a great deal about how software development works. Not necessarily the details of how to write code, but information about the overall arc of a project, system design and architecture, and other things that help to clarify what to expect from the project and the relationship.
2. Goals Are Realized Through Iteration
One thing that being a scientist has taught me is that you can never be certain about anything. You never know the truth. You can only approach it and hope to get a bit nearer to it each time. You iterate towards the truth.
– James Lovelock
No matter how clearly a client believes they understand their software needs, that vision is probably going to shift during development, in at least subtle ways. A colleague of mine likes to say that the most common way to know what someone wants from software is to build what they ask for, and let them tell us how it’s wrong. Tongue-in-cheek, perhaps, but with an important kernel of truth. And the critical point is that this doesn’t point to a shortcoming on anyone’s part; not an irresponsible developer or a vague client, it’s simply how creative work goes. We iterate until we get as close to the ideal vision as time, resources, and technology will allow.
This doesn’t mean that a project plan, carefully thought out requirements, and mockups aren’t important. Those are all critical elements of a successful project too. But to take them as etched in stone, and assume that the project will proceed exactly along those lines is unwise, and indeed stifling to the end product as well as to the relationship. The days of throwing requirements over the fence and expecting the developers to scurry away and deliver a completed project six months later are gone, and in fact those days generally ended in disaster.
The way to embrace this reality is through iteration. Developers tackle discrete pieces of the project, provide releases every few weeks (or more frequently in some cases), clients review these releases and provide feedback, and everyone takes stock of what’s left before launching into the next milestone.
There are a number of ways this can break down (we sometimes call these “anti-patterns”):
-
A developer may work for too long without providing a release, potentially going down a path that doesn’t make sense upon review by the client. This wastes time and money.
-
A client will be too busy or distracted to provide timely feedback on the release. The partnership suffers from the lack of client participation, and the developer loses confidence that they’re building what’s required.
-
A client will not realize that the release provides limited functionality, and the relationship may take a hit from what appears to be a broken work product.
-
A developer may not communicate clearly what the client should be expecting to see in a given release, contributing to that sense of concern.
Again, communication and a balanced partnership are the keys to success here, but with the added element of understanding that development is more of a side-to-side traverse than it is a marathon run directly up the side of the mountain.
3. Expect Unpredictability When Building Something New
To expect the unexpected shows a thoroughly modern intellect.
– Oscar Wilde
Custom software development, like all creative work, is inherently unpredictable. Anytime you’re building something new you will be faced with new problems and challenges. While it’s not possible to anticipate what these may be, it is possible to plan for the appearance of the unexpected. Budget and schedule are two areas that merit discussion.
Projects generally start with an estimate. In most cases these reflect the developers’ best efforts at understanding client requirements and predicting the effort needed to implement them in code. They won’t be perfect, however. Even the most skilled estimators are still making educated guesses at what they may find once they begin. Some examples:
-
At the time of estimation it’s generally not possible for the developers to understand all of the ramifications, interactions, and subtle details of every requirement, so there will be more to learn.
-
Technical problems will arise. Most projects will encounter some frustrating limitation in development tools, operating systems, documentation, even hardware. I worked on one device driver project that encountered a hardware timing problem on one specific variety of Mac. Only a particular run of the motherboards was affected, and the problem was intermittent, yet resulted in a devastating system lockup when it occurred. Obtaining the right machines, learning more about the problem, and devising a workaround all reflected excellent detective work, but the real key to success was having a supportive client who knew that this sort of thing happened, and saw that we were doing good work in a challenging situation.
When the budgetary estimate comes in at the very top of what a client can afford, project risks skyrocket. A company should build a safety margin into the estimate, but even that is speculative, and generally assumes some average level of risk. If a project is critical to complete (and most of them are) it makes sense to have some budget in reserve, potentially up to 50% of the originally estimated amount. If that’s not an option it can help to be prepared to triage and defer features, in case of emergency. It’s often more effective to get a release out there with some functionality, see some return on investment, then implement the remaining features in an update; than to break the bank struggling to complete every bell and whistle prior to release.
Schedule should be viewed similarly. Certainly all of the previous issues can impact schedule, delaying a marketable version of the software. In addition there’s the fact that developers are human beings and may become ill, leave for new positions, or any number of other things. A good development company will have other options; ways to smoothly ramp up new developers if necessary, for example, but there will still be an impact.
4. You’ll Need to Develop Trust to Weather the Challenges
The best laid schemes o’ Mice an’ Men, Gang aft agley.
– Robert Burns
The most fundamental thing to expect from a relationship is that there will be challenges. That relationship will be strained by the unexpected, by human failings, by miscommunication, and countless other things. To expect otherwise is unreasonable. Again though, it’s possible to plan for this. The much vaunted “relationship capital” comes into play here. When that trust has been intentionally cultivated between client and developer, when there’s been regular communication, periodic releases that show progress along the course laid by the project plan, and honesty and transparency all the way back to the beginnings of the relationship, there’s a good chance that the partnership will be strong enough to survive.
I’ve been fortunate enough to work with some clients for decades. At this point I consider them friends, in addition to clients. We understand each other and trust that we’re going to each do the best we can to bring things to a successful conclusion, and to keep the communication lines open about anything that puts that outcome at risk. It’s harder with a new relationship. It takes conscious and repeated effort for two parties to develop that comfort with one another.
It’s also worth noting that expressing that confidence can have a profound impact on the relationship. People like to be appreciated, certainly, but beyond that is the fact that a real partnership provides support for people to do better work than they might be able to achieve on their own. Having a client tell me that they know I’ll be able to figure out a solution lends a sense of being in it together, and often helps me to break through and discover a new approach. A development relationship is a risky alliance, but it can also be immensely productive, and even resilient, with a little preparation.
