In software development we are constantly looking for the Next Big Thing. We haven't given up hope of the silver bullet... one day it must show itself.
It might not be the silver bullet, but I bet a nickel on the next big thing being small, extremely small. We are at the beginning of the era of tiny.
We've had three different eras:
- The era of following one big vendor and nothing else.
- The era of using many large open source frameworks.
- The era of tiny.
If we go 10-20 years back in time, we find ourselves in the time I call "follow one big vendor and nothing else". You found all you needed at one single place. It seemed to be simple and it seemed to be safe. You were taken care of and didn't have to think for yourself all that much.
Often the tools helped you quickly create loads of ugly code that you then had to maintain. There was a lot of focus on "drag till you drop" instead of writing code.
Large database oriented programming models and large solutions to create the illusion that it wasn't the web when you were developing for the web were often used. When the vendors were demonstrating their solutions they often said: "And all this without me writing a single line of code." When you looked at the result behind the scenes it made you cry, but not tears of joy.
After a while some people lost their tempers and there was something of a revolution. About ten years ago and up until now there has been more and more focus on open source and strong communities. Large, generic and important frameworks grew up and were used a lot. Let's call this era the "use many large open source frameworks".
The focus was on agile development, DDD, elegant code, TDD, craftmanship, MVC, O/RM and REST. A lot was good and sound, but a common problem was that whoever used the most number of design patterns in his solution won. It was also now many of us learned – the hard way – that large, generic frameworks shouldn't be invented. The chance of success increases radically if you harvest them instead.
The third stage which is currently emerging is more evolution than revolution. I call it "the era of tiny".
A lot is still around from before, such as test-driven, real DDD and focus on superb code. However, there is a little less focus on using communities and open source projects in order to find all you need in the form of large generic frameworks.
Instead the focus is on turning inwards and solving tasks with tiny, specific framework solutions without all the unnecessary extras. An alternative is to have dependencies to extremely small code snippets that solve one single specific task in a good way. Often those are used as code instead of as binary.
A typical example to make the cooperation between developer and client even better is to use domain-specific languages so that the documentation is also executable.
If you receive the following comment...
Have you solved the problem with that tiny solution? That's not very "enterprisey".
...then you have done something good.
(First published in Swedish as a developer chronicle here.)