The customer is always right… until they aren’t.

One thing about software development is that it is complicated to get right. The difference between a request that takes a few days to reach proof of concept and something that is at a postgraduate research project level can be very difficult to distinguish. And the landscape is constantly shifting.

To further complicate this, almost all software requires a host of disciplines to not only pull off but to create something that will be successful. Security, user experience, performance, scalability, and accessibility are just a few of the skill sets that contribute to success in this space.

The thing is, many of the companies we work with are not software companies exactly, but companies that depend on software to run their business. They can’t afford to get these things wrong. If you follow the news, there are often stories of a company that is in a predicament because software didn’t quite get it right.

Without naming the names, here are just a few instances we’ve seen in the news recently. Customer data breaches, accessibility lawsuits, customer base erosion, leaked data, failure to launch. In all of these, I can guarantee a developer knew something wasn’t quite right before the failure occurred. If your developers don’t tell you no at least some of the time you can almost guarantee some of these kinds of problems are lurking in your software. As a company primarily made up of software developers we believe much of the responsibility is in their hands to help educate and provide insight to the client.

In the book, Clean Coder, industry leader Robert (Uncle Bob) Martin devotes an entire chapter to the professional skill and importance of developers saying no. At Midwestern, we believe so much in serving you that it is part of our motto, “serve each other and serve our clients”. However, we believe that service includes being candid about blindspots in the plan, the feasibility of hitting a target, important opportunities, and the like. We are your strategic partners to give you the best chance of success possible. Recently I’ve personally observed our team push back on release schedules that couldn’t be hit, raise security concerns where PCI compliance was at stake, help refocus on stated goals and away from expensive side issues, and question poor usability choices.

There is a skill to this, I had to learn the hard way that some things work better than others when communicating this. Often, young developers know a customer request is impossible, and will just say so. One of the things we train our developers to do is to stop right there and seek to understand the business need behind the request. There is almost always something reasonable behind it and almost always some equally reasonable way to accomplish it. We only arrive at that best-case scenario by partnering together to work in that professional tension.

We have seen teams that aren’t comfortable enough or don’t think it is their responsibility to disagree to the detriment of the client and project. Our goal is to “serve the client” and part of that includes some healthy, respectful pushback in pursuit of your goals. This is how we like to work and we’d love to work with your team to achieve success.

‍