Why the Rebellion Begins?
Throughout my career as a software engineer, I used to work on different projects, for different companies; each one having specific cultural and methodological approaches to organizing people and to developing software. However, some of the internal issues they were struggling with were almost always the same:
- Lack of communication between team members,
- Lack of abstractions in their work,
- Obsolete or no project documentation at all.
What Problem the Rebel Solves?
It was common for people to be working for years on a project, very responsibly, without having wide picture of solution they were providing. Also, domain knowledge was often treated as something clearly separated from the technical knowledge. Therefore, the majority of team members almost had no domain knowledge and were focused mostly on solving “technical issues”. To me, it is still difficult to imagine software developers solving domain problems they do not understand. When it came to mutual discussions, everybody used to imagine his own mental picture of the program and were frequently using different words to refer to the same domain concepts.
Also, it was very common to bind assumptions on implementation, rather than interfaces, violating some of the most basic software engineering rules. And when there were times to switch some particular service providers, due to lack of abstractions, we were facing major project refactoring and change, coping with stress, risk and working overtime.
Finally, it frequently used to happen that there was no documentation at all (“our code is our best documentation”) or that documentation was obsolete and inadequate. As a consequence, it used to take months, even years for new engineers to get started with the project.
Luckily, it was not always like that.
The Solution
In one of my previous companies, we relied heavily on Model Driven Development. We developed our custom code generator as a plugin for the previous, open source version of the StarUML. And that was the moment our revolution truly began.
Our projects all had a live visual map – project UML model, that was enabler for efficient discussions and analyses. Change in the model was automatically propagated (by the code generator) to different executable artifacts: Java source code, database schema or a web service. Our documentation, based on the model, was always accurate, but the most important difference was the change in our mindsets!
Our focus moved towards thinking and visualizing instead of coding and we invested more efforts into creating quality (internal) designs of our solutions. Model Driven Development and our code generator enabled us to focus on overall project design before diving into details and spared us from writing boilerplate, repeating code.
We were close to what I see as a future of software development. Our toolset automated parts of development process and let us focus on more important challenge: deep understanding of the problem we were solving. From that ground inspiration for the Rebel came from.
I disbelief there will ever be an automated toolset that will solve all important issues that we are facing as software developers, but I already know there are tools to help us develop with more ease and joy. I truly believe that the StarUML along with the Rebel are one of them.
