Update : french people can find a talk I did in Paris Java User Group inspired by this article here
Introduction
During the various mis...
For further actions, you may consider blocking this person and/or reporting abuse
Ouch - yep! On a positive note, there are at least well trodden paths now to get out of these messes, removing coupling, improving cohesion and giving teams some autonomy back:
thoughtworks.com/insights/blog/mic...
martinfowler.com/articles/break-mo...
databaserefactoring.com/
highfive.com/blog/how-spotify-buil...
Thank you for this great article. Been there done that.
My philosophy - which is frowned up along my colleagues - is simple and counterintuitive:
Build disposable software. That's it.
Abstract as much is needed to allow throwing complete parts of your software out of the window.
This is not, what we are taught - mostly. We are taught building cathedrals of architectural beauty and purity which could potentially last forever.
But from my experience it doesn't pay - from a business perspective - to invest much in lasting architecture, because business changes often enough. And here disposability is an advantage.
That doesn't mean that you do not have to care at all: on the contrary!
It is more like TDD on scale: do the minimum architecture to solve the current business problem. And if done correcly - like in TDD - you could throw the current implementation out of the window and do something new.
If your architecture became a burden, you made it too heavyweight.
I think I have worked on all these architectural burdens, and created a few myself. Come to think of it I developed my own rule management engine (also for an ETL process) where the rules were represented as SQL statements. At least I used an ISO standard language. :)
Probably my most painful designs were the ones where I built a framework for the app. You had to plug your object into it to have plumbing automatically handled for you. That would be fine, except the next feature request was usually an uncommon case. Then I ended up having to refactor the framework to handle it. Then the objects you plug in end up depending too much on the way the framework operates, so they have to be refactored too. This experience is why I now prefer the framework-less approach to the apps I build, and functional programming in general. It can be a little more work up front, but way easier to maintain.
I would really like to see a well thought out path to solution a large shared database. My team struggles with this and we know it’s a problem.
Oh, microservices? So we build out microservices to cover all the needs for accessing this data. The vast majority is read-only, since its ERP data, so it should be easy to do that.
But wait, a year later we need to modify one of those microservices to add a field to the output of some endpoint. Who owns that microservice? We’re in the same problem you described with the database, with the bonus problem of much higher latency.
How do we avoid the same problem now? I would love to consider these microservices as disposable, but it’s almost impossible to think of things that way in enterprise development. There are 10 applications using that microsevice now, and it definitely seems like a bad idea to add cruft for my edge case to it.
Great post and I recognize a lot of this pain. This is definitely one of those things that you run into throughout your career that can make you feel deflated. However, these are decisions that can be undone. The process is just longer and more tedious than others.
Yikes, I definitely recognize some of this. Great post.
Thank you ! Unfortunately, I think most developers faced or will face at least one if these issues in their careers.
Great post,
and I'd love to read more about how you solved these issues.
Easy if you could just restart from scratch, but I really don't think you could every time... :)
Riccardo
Unfortunately, I didn't have the occasion to solve all these problems. The team and the management was often conscious of the situation, but it was difficult to spend enough time on technical subjects compared to the business requiring new features. But in some cases, we were able to achieve a lot regarding decoupling with other applications: removing all dependencies to other teams classes, using REST APIs (using Spring Remote HTTP mechanism to avoid a big bang change), replacing communication via database with REST APIs or messaging... We also started to use our own database schema, while still feeding the lecacy one, so that we could progressively migrate to our own model, but this will be quite a long road!