That’s Brit and I in Pisa, Italy having a close look at advanced engineering. Fortunately for us (and you), we build software better than the Italians build towers.
The key to high quality repeatable results is having a method to the madness. In our case, we use a process I created about a decade ago called the 4D Methodology. It is an agile manifesto that lays out the steps a software team can take to define, design, develop and deploy a complex custom software project.
Copyright notice: No part of this website may be reproduced, distributed, or transmitted in any form or by any means without the prior written permission of MyProgrammer, Inc.
Okay, that’s not entirely true. We could spend hundreds or even thousands of hours solving the wrong problem for your business. I’m just not sure you’d be happy about it. So we first need to define its requirements.
To build useful custom software, we need to understand your industry, business processes, overall goals and a bunch of other important details. The define stage of our 4D Methodology is intended to provides those details.
What does software design really encompass? Let’s assume we are designing a new kitchen. What goes into that design? You first need to consider the space you have. Are you going to have two double ovens or one? You play around with a few sketches until you are happy with the solution.
Yeah, custom software is nothing like that.
Just kidding. We follow the same thought process. Instead of space, we think budget, both in cost and time. Instead of two double ovens we focus on features. We also put together sketches (called wireframes) to help everyone visualize the solution. We design the user interface, database structure, software architecture, and a bunch of other areas critical to software development.
When it comes to building custom software there are a lot of horror stories. Broadly speaking, bad software is hard to use, hard to maintain, and expensive to create. All three of these issues usually lead to a very short production life.
Call me old-fashioned, but I like to avoid those mistakes. How do we do that? First, we want your software to be a big hit with your users. So it has to be easy to use, and solve the problems your users face efficiently. Second, the underlying code needs to be written in a way that it can be upgraded easily. Following industry best practices helps. And finally, we need to be cognizant of your budget, and avoid sticker shock.
We also want to plan for success. I know, novel concept. We expect your software project to be a big hit. The software architecture has to be able to scale to handle that success.
You might think that your custom software project is done when the application is deployed on your server, or in the cloud. And yes, we handle all of that stuff. But while that is an important milestone, deploying your custom software is where the real relationship begins.
Think about it. We might spend months developing your software application. We hold lots of meetings, discussing the various features your software requires. We go over design comps, the database schema, and tons of other details. This is what I would call low pressure activity.
Once your software is live, this is where the rubber meets the road. The entire cadence of the relationship changes. We need to be Johnny on the spot, dealing with anything urgent as quickly as possible. And it’s a long-term relationship. We have worked with clients (now considered friends) for 20 years. My point is that deployment marks a new beginning, and not an end.