5 things your software developer doesn’t want you to think about
In this short little click-bait article, we’re going to give you some quick thinking-points on 5 of the big problem areas we’ve seen on custom software projects over the years. If you’re shopping for or engaging with a software solution provider – including Fancy Awesome – give these some thought.
There can be so much focus on getting to that first release that often the technical and business reality of maintaining a deployed solution is an afterthought. Almost everything has a cloud component now, so you need to be negotiating where and how your software will be hosted on the cloud. Understand the recurring costs, flexibility to scale up – both in the hosting provider and the architecture of the software – and establish who will be maintaining online services on what terms. You also need to negotiate how the code will be maintained because there will be unforeseen bugs and needed features. Get those terms nailed down up front, or you could find yourself in a compromised negotiating position after release when your developer would be in a position to dictate terms for those services.
Your developer should be able to communicate about the technology choices they’ve made in terms you can understand. Every project is composed of different platforms, libraries and services we call the tech-stack. These are things such as HTML5, Java, .NET and SQL Server. Your developer should tell you what tech-stack they are proposing, what the alternatives are, and why they recommended the tech stack they did. Often the answer is “because this is what we know best,” which is realistic, but then you might need to shop for alternative developers familiar with different technologies. We’ve talked to a lot of people with systems that were built on a tech-stack that was convenient for the developer but left the owner high-and-dry when it comes to finding alternate developers to maintain the system later.
#3 Quality Assurance (QA)
It’s just a fact that the human mind cannot anticipate all the permutations that a software system might encounter in the wild. Your developer needs to have a quality assurance plan. In book publishing they have editors that check the work of the writers before it’s seen by readers, and it’s a similar idea for software. Developers are often pressed for time to write new feature code and check that the new stuff works; cross-feature testing to ensure the newly added code doesn’t break old code is too time consuming for them. Also developers are usually bad at spotting their own mistakes, and QA people cost less than developers. But don’t fall into the trap of trying to reduce costs by just doing it yourself; software testing takes 20-50% as many hours as development and requires specific technical skills.
#2 Total Cost
What you need is a working software system. You need to see an end result, not just effort. All too often when we’re bidding on projects or talking to new clients about rescuing their project gone awry, we see these low-bid – often off-shore – developers who charge very low rates. However, these chop-shops don’t ever actually deliver anything of use and cost the client far more time and money in the end. Frankly, we don’t even want to talk about rates because we’re not interested in selling hours of our peoples’ time. We sell working software. So keep your actual goal in mind – you want a working system for the lowest total cost. It’s a very simple equation: hours times rate equals cost. If you get tunnel-vision on rate, you’ve lost the game. If your developer cannot give you contractually binding guarantees on your total cost that you are comfortable with, then you are signing a blank check on both your money and your time.
A lot of software shops are pushing Agile or Scrum development methodologies where you figure it all out as you go. It seems just about every custom software shop has some variation of the Scrum cycle diagram (LINK TO IMAGE OF IT) in their slide deck now. There is a lot of wisdom in those iterative methodologies – that we use too – but that is all about the journey, not the destination. Before a line of code is written – ideally before you even sign off on principal development – your developer needs to demonstrate that they speak your business language, understand what you actually need in detail and sketch out both the user experience and a system architecture. They need to start with a solution even if it doesn’t end up being the solution, or once again you’re signing a blank check on your money and your time.
Thanks for reading!
We hope that you find this and read it before you start your project and that it gets you asking the right questions. We die a little bit inside every time we hear about failed software projects because it usually didn’t have to go that way if the right questions were asked at the onset. These are just some of the issues we discuss up front with every potential customer. We find that the more a customer is educated on how software projects actually work, the better we look as a development partner.
Please give us a shout if you’ve got a software project coming up. We know we cannot make all the software in the world or are even the best choice for every project, but we know a few reputable developers we can point you to if need be. If you already started your project with another developer and have concerns, we offer auditing services to give you an outside, expert assessment, and we do not treat such engagements as sales opportunities. We charge a fee and give you an assessment backed up by facts, not conjecture. And finally, if you think it’s too early to talk to us, reach out anyway! We’re always happy to provide advice as you explore your options.