blog

Photo by Markus Spiske on Unsplash

Socks and Sandals (and software-development faux pas)

by

I’ve worked with a lot of clients and potential clients over the past 10+ years. Sometimes, in conversation about a project, the client will roll out, oh-so-casually, one of about 10 pat statements that reveal a pernicious and erroneous belief about the process of software development. Now, most of my job involves educating clients so I take a deep breath and wade into the waters of a software-development ideation faux pas, of explaining why what the client has just said is analogous to pairing socks and sandals: Sure, it makes sense on one level, but it’s never a good idea. (Note: I’ve been chided by our development team that wool socks and Birkenstocks are certainly acceptable and that Keens and short anklets are also acceptable. I sigh. I choose to fight my battles one at a time. . .)

Moving on.

The objective here is to give the audience a bit of quick and dirty insight that, I hope, will help clients be . . . well, better clients. Better clients always, without exception, mean a more successful project — cheaper, faster and far, far fewer hair-tearing-out incidents.

My top 10 software development misconceptions, Letterman-style:

10. “There shouldn’t be any bugs in the code I’m paying for.”

Okay, so first, bugs aren’t negligence or screw-ups by the developer. Bugs occur because, as much as you try to write code that a chunk of hardware/OS understands, because that OS/hardware is, despite all appearances, simply stupid, sometimes what that hardware/OS spits back out isn’t what the human wants or expects. Bugs, when dealing with a qualified and experienced software development team, aren’t about good work versus bad work but about process.

And consider this: You know those update notifications that you keep getting from Apple or Microsoft or Firefox? Those are updates that address bugs. The largest software companies in the world create buggy software. It’s just an inevitable part of the process.

9. “We’ll test it ourselves.”

Erroneous belief: By testing it “ourselves” we’ll save money. Nope, you won’t. Code isn’t “done” until it’s tested. Software development companies have dedicated and, frankly, oddly masochistic and freakishly persnickety QA professionals who can ferret out issues you don’t know are there faster and more efficiently than you can. They are able to capture and relate issues to the dev team in a highly specific manner that ensures they are fixed. Save yourself time, money, and severe migraines and have your development company test your application. You’ll have your chance, but what you’ll be testing for the workflow-centric issues only you, with your domain expertise, will find. And your QA team will provide a tidy test plan to follow to validate functionality. Worth every penny.

8. “We’ll design the UI ourselves.”

See above. Designing the UI/UX yourselves only works if you are, or have on staff, a web designer with experience developing UI/UX for web applications. UI/UX designers do more than make things look good. In fact, this is pretty much the last thing they worry about. They are trained to implement UI/UX designs that support user workflows intuitively, organize information in the idiom of software, create interfaces that limit user error, ensure that folks with mobile devices don’t hate you and that those with visual limitations, amongst others, can navigate your software successfully. And that’s just the tip of the iceberg.

7. “We’ve already written the spec.”

You want your chosen software development company to write the specifications for your software application. I promise they will ask questions you didn’t consider and those questions, in my experience, are frequently crucial to the business objective of the application. The iterative process of questioning and working through an application’s specifications with a client can identify costly gaps in logic and functionality. I’ve repeatedly been surprised by the ability of developers to sight and identify issues that clients are unaware of existing. And if one is aware, one can plan. The process of writing specifications for a project sets the project up for a successful, smooth implementation. It’s akin to measuring twice and cutting once.

6. “We’ve scheduled a product announcement in 5 weeks.”/ “Our marketing division has already issued a press release.”/ “We need to make a decision on a vendor by the end of the week. I know we just had our first call, but can we have a proposal by Thursday?”

I ask – I beg, really – that you please consult with your ever-so-collaborative development team before you make any business-level decisions about the software that they are building for you. Set yourself up for success and do this; the team will help you set expectations and ensure you aren’t embarrassed in front of your audience. I also ask that, when considering a software development effort, you begin the process of finding the team who will be responsible for the success of your effort as early as possible. You have my permission to tell whomever told you to hire someone in a week that their expectations for finding the right team to implement your business critical software are unreasonable and dangerous.

5. “I want to prioritize schedule, budget, and features.”

It’s the rule of production: You can pick two. You cannot have all three. If you want it fast and cheap, you’ll need to cut features. If you want it fast and fully-featured, it’s going to cost more. And the most cost-effective way to implement a large number of features is to extend the schedule and keep the team small. Makes sense, right? Closely related to this is. . . .

4. “We want to add more stuff. We can stay on schedule if we just add more developers, right?”

This is the Mythical Man-Month. . . er, myth. Projects have a Carrying Capacity, a point beyond which they become unwieldy and collapse on themselves like a souffle. No one wants that. In some cases, the development team can be scaled up slightly to get more done, but this isn’t infinite. Imagine cramming more and more people into a small room and asking them to build something intricate. It’s not pretty. You also shouldn’t expect that by breaking the project up into parts that you’ll get a huge bump in efficiency. At some point, everyone needs to dance very closely together to integrate all of these components. Two people dancing is one thing, five people dancing is another.

3. “Until you’ve completed 100% of the requirements on this very long list, we can’t show it to anyone for feedback.”

Software is a living thing and it exists in relation to the humans who will interact with it. Get comfortable with the idea that your software will evolve over time in response to both technology and your users’ needs and expectations. I’ve had whole swaths of planned features abandoned or reimagined in response to early user feedback. I’ve had clients stunned by the need of their users to have a feature that they hadn’t even considered. Releasing your application early to users will give you valuable insight and keep you from implementing features no one likes or uses, which then have to be replaced or abandoned. This resistance to getting feedback is a waste of time and money. Build what your users actually want, not what you think they want.

And in the case of a software product or service, releasing early means the application will begin (hopefully) earning income that can then be used to implement user-requested features. Win!

2. “Is just a little change.”

Sometimes, yes, this is true. Sometimes it really, really isn’t. Be prepared to admit that what may seem simple to you may require considerable reworking of the application. “Considerable reworking” is code for time- and budget-taxing. It can be hard, sometimes, to let go of what feels easy in the face of what the development team is telling you about a change, but you need to do that.

I’ve found that, frequently, this statement is a result of the delta between how our magnificent human brains process information and make connections and how software handles changes and connections. We assume that since our brains can do something easily that an application can as well. This isn’t always the case.

Trust that developers LOVE little changes that really are little changes.

And, my #1 most cringe-worthy client statement? The innocuous:

1. “Oh, and reports . . . we need a few simple reports.”

What I’ve said above, about how our human brains manage associations, is especially true about reports in software. Clients tend to spend a lot of time thinking about how to get data into an application and less time thinking about what they want to get out of it. Getting data out in a meaningful way IS THE HARD PART. Reporting can be incredibly difficult . . . and it tends to sprawl. A few simple reports frequently give rise to custom reports across multiple axes of analysis. And graphs! The results of these reports are incredibly easy to visualize and their need is obvious, but making that happen can be tedious and tricky. We employ a DBA here to do just database development and reporting – that’s how onerous it can be.

+ more