Probably every software developer – since the 1990s at least – has been there once, asking him- or herself: “Why do I have to write tedious, repetitive CRUD code time and time again?”
Being good, virtuous programmers some of those developers did what software development in the end mostly is about: They tried to automate a cumbersome, repetitive process that like any repetitive process should be performed by machines rather than humans.
Some have succeeded – to some degree at least – others: Not so much.
So, why is it that today we still have to manually create applications that read and manipulate data from a database from scratch? Well, one of the reasons for this quite likely is that although all those boring run-of-the-mill database applications technically look the same on the surface the devil’s in the detail:
- Not every database has a well-designed, normalised structure.
- Most apps need to take aspects like authentication / authorisation, notifications and logging into account.
- Specific deployment environments like Java EE application servers can bring about additional, non-functional requirements.
This gives rise to small variations between those apps, which in turn prevents a one-size-fits-all approach for application generation.
The main reason why developing this kind of applications still is mostly done manually though in my opinion is that generated code often is less readable, less testable and less maintainable than code created by human developers. Scaffolding or code generation tools tend to create lots of ceremonial, cargo cult code that often is only needed by those tools in order to be able to later modify the generated code again.
Even more trouble arises if that generated code needs to be extended in order to accommodate specific, bespoke business logic. This over time usually leads to the codebase diverging from the state originally generated by the machine, which makes regenerating and synchronising the code with database changes all the more difficult.
This somewhat sorry state of commonplace business applications is even more deplorable as programming languages like Delphi and their accompanying tools have allowed this semi-automatic creation of software from data models for quite some time now. Let’s not forget though that the Delphi mostly lived on single-user, single-client systems running Windows. Much of the complexity modern networked web applications have to deal with simply didn’t exist back in the day.
Still, I think there’s much to learn from tools like Delphi or Ruby on Rails (which I by no means intend to sound like Rails being outdated technology). We have to do better than that if we want to truly advance software and the business of software.
Therefore in the next few weeks I’ll write about some tools that I think help with developing CRUD database applications. None of these is the Holy Grail – the be-all and end-all to all software development woes but they can help tremendously with easing and speeding up software development processes.
Pingback: Swagger: A Roundtrip Tool For Creating And Consuming REST APIs | Björn Wilmsmann