In the game of baseball, the “sweet spot” is a place on the bat which is the optimal place to make contact with the baseball. When you swing the bat with conviction and connect with the ball in this sweet spot, the ball is going to travel further than if you were to hit the ball on any other spot on the bat. It doesn’t necessarily matter how strong the batter is or how fast the pitch was: the sweet spot will produce the optimal result – a baseball hit “out of the park” as they say.
Success in life really comes down to finding the sweet spot in the difficult things that we do. As a parent, you can’t be too soft nor too stern with your children. For most of one’s life as a parent, we are searching to find the right, and often elusive, balance. For example, one extreme would be letting your child do anything they want without repercussions. The other extreme would be not letting your child do anything and punishing them if they do. Most parents would agree that either extreme is not the right approach. And if you have three children, you have to find the right balance for each of them because that balance is often different for each child.
Finding the sweet spot in parenting, in baseball, or in anything we do, involves finding an optimal point of balance between two extremes.
CaseHub, the workflow engine of our AdjustmentHub™ case management solution, is all about finding the sweet spot in a low code solution that is somewhere between two extremes. One extreme is where the solution is very simple for non-developers to learn and use, but is thus often limited in what it can do. The opposite extreme is a very powerful solution, but is often very difficult for non-developers to learn and use.
Interestingly, most people do not realize that low code solutions have been around for some time. COBOL in fact could be described as one of the first attempts at a low code solution. It was designed to use the English language to describe functionality and thus be more “accessible” than other programming languages. There was a trend in the past called “Fourth Generation Languages” or 4GLs. The fact that most of you have not heard of them shows how successful that trend was. But, I digress.
In order to move forward, we must learn from the past. And, it is my contention that the reason that the 4GLs in the past were unsuccessful is because they did not find the right sweet spot between simple and limited vs powerful and complex. The 4GLs veered too far towards the “simplicity” extreme and thus weren’t powerful enough to accomplish difficult projects.
When considering where the sweet spot may be, it is important to understand what makes developers different from “normal people” (being a developer myself, I can get away with saying developers aren’t normal). While there are certainly some very smart developers, developers are not, in general, “smarter” than non-developers. Developers just think about the world in different ways. Essentially, they are able to see the world from a computer’s perspective. This is important for defining the sweet spot because we need to remember that there are many very smart non-developers who simply aren’t …programmed… (insert eye-roll) to see the world this way.
This informs us as to what we create in the “Complex/Powerful” category – the stuff that requires someone to think like a computer in order to understand:
- XML, JSON
- HTTP
- SOAP/REST
- Complicated SQL
- Database indices
- Java syntax
- Script language syntax
But, it also allows us to add items in the “Simple/Limited” category that other low code solutions might not:
- Three tier design
- Data model
- Business logic
- Presentation
- Relational database structure
- Table/field schema
- One-to-one relationships
- Many-to-one relationships
- Open-ended visual business logic definition*
- Software development life cycle (SDLC)
*3GLs and script languages have syntax that is difficult for non-developers to understand; however, non-developers do understand and can build complex business logic if you use a visual development environment that takes the syntax out of the equation.
We have done extensive validation of this approach using our non-developer Lean staff (whom we call Visual Developers) and achieved success. We have found our sweet spot. Our visual developer team has the tools and the training to implement most of the complex business logic in our applications with limited assistance from our traditional software development team. At the same time, our traditional software developers can focus on addressing the more complex aspects of computing technology.
Why is getting non-developers involved in the development process so important? I will cover that in a future blog entry.
Greg Cooper is Vice President of Product Development at Lean Industries. He manages product innovation, architecture and software development activities at the company.