Last week a customer/partner was in town from Germany kicking off a new project.
This person works in the manufacturing industry, consulting to his customers in the manufacturing space in Germany. Every time I’m with him, I’m always amazed by the German ethics in terms of making a product. The stories he tells regarding how his customers engineer and build their products; the capabilities of the plants he works with; the passion for quality that these manufacturing giants have — all are awe inspiring!
After I left him for his return trip to Germany, I was driving back to the office thinking about an internal debate we were having at Spieker Point. The team was in a discussion the other day regarding the quality of software that we produce. We write software to last. The children of our customers could use the software years from now when they’er out of diapers and grown adults (if Microsoft doesn’t stop deviating from “standards” with their browser).
There are times when customers wants a lower price point. One way to deliver that is to offer something that is lower quality: a project that will let the customer do what they want – but no more. Ever. 6 months from now, you want to blow out the walls and make a big extension? Forget it; it’ll be way cheaper to rebuild it for your new requirements.
This is NOT the we approach projects. We never dial down quality to move the price point. We write stuff that has a solid foundation, meeting the current and future needs the client has told us about. As an analogy, a client wants a 60 floor building, but they want to start with only 2 floors for the first couple of years, having the ability to add onto it later. When they come back to us 6 months after the first release, there is NO problem adding another 5 floors right away; the foundation is designed for that…
The recent discussion with the team, and what I was thinking about after hearing more stories about the amazing German manufacturing industry: as a group of high-end professional software developers, we have a firm grasp on the quality dial – should we ever dial it down?
There are lots of low quality software developers out there who deliver low quality, cheap software. They’re often so low quality, they have no idea how to dial the quality knob up and deliver on the opposite end of the spectrum. And there is no way to extend their project when the requirements change after initial delivery – and they ALWAYS do.
Lots of companies deliver both low quality “fighting brands” and high-end solutions. Car companies (GM, Ford, etc), computer companies (Acer, Dell, etc), software product companies (Intuit, etc), cell phone carriers (Telus, Rogers, etc). But others choose to compete only with high quality products. Mercedes, Apple (who also does an incredible job at support on top of high quality products), SAP, etc.
But we’re a 10 person company who’s been in business for 7.5 years (as of this writing in January 2013). We consider our competitors to be companies with three letter acronyms for their names, as well as a handfull of other small, highly skilled boutique development companies.
We know how to adjust quality to deliver a cheaper project. Yet, we’ve never done that. It seems that neither have the German manufacturers.
Should we deliver lower quality to compete – on price point alone – with the lower quality developers?
Would you mess with quality?
While customers want lower budgets and short timelines, they will be the first ones to complain if they find an issue in your functionality. We have learnt that software quality is also about managing customers expectations and educating them sometimes. This involves reducing the scope of the requirements, testing critical functionality first before the bells and whistles.
I completely agree that customers will complain if there is a functionality issue (buggy software). I’m not suggesting for a second that releasing “buggy software” is the mechanism for reducing quality. I’ve tried to suggest only releasing enough functionality and infrastructure to get the software running properly for the problem domain, and nothing more. If extensions or other functionality are requested into the future, they might be more expensive than if we had used our experience to build forethought into the software from the start…
I really appreciate your comment!