Everybody wants a silver bullet, a tool or process that will dramatically simplify their activities and reduce costs. Companies are investing more money than ever towards that objective. However, we’ve found that most obstacles companies face, and therefore most of their budgets, are going toward human problems instead. One of the biggest cases of this is developers playing telephone with computers.
Let’s say your developer’s name is Michael. Michael translates your business requirements into code. That’s like translating Homer from Ancient Greek to Vulcan. Sounds hard, but it goes well until Dwight comes along. Dwight interprets the original goal from Michael’s code (which was written at 2am with a lot of Red Bull). Meanwhile, Pam and Jim are attempting to achieve yet another goal by playing off of each other’s code (and cleaning up Dwight’s mistakes). Obviously this is a recipe for disaster. People will quickly lose sight of the original goal, and may even start fighting each other. (If you want more examples, check out this lament on stilldrinking.org)
A better approach is to write Declarative Software: Software that sets goals in near plain English, then teaches the computer to implement those goals. We do this in several key ways:
1: Application Settings
We might add settings into the software to allow admins to define and change goals in a simple interface, then teach the computer what those settings mean, and how to interpret changes.
2: Application Configuration
For goals that don’t change that often, we might build in configurations into our database or code that define those goals as closely to plain English as possible. If goals change, a software change is a file update away.
3: Application Design
We define every feature of our applications in GraphQL, a language invented by Facebook. GraphQL takes about a weekend to learn, and is about as close to plain English as you can get. Then we teach the computer how to do everything in the GraphQL definition, and automate a bunch of the boring details. We check our alignment with these goals all the time. If a developer deviates from our definitions, he gets a red squiggly line under the part of his code that isn’t correct.
Finally, we foster a culture of communication. There is no substitute for a team that cares about making a difference, and will openly discuss problems without blame. We all love software, but we love people a lot more. We’re more than willing to go the extra mile to make sure our software meets the goals it was intended for. If you need help getting a project back on track, or you just want to set your project up for success, don’t be a stranger. We’d be happy to connect!