I for one believe that the best solutions I've produced over the years were things that side-stepped the popular or established frameworks and were more customized and focused solutions.
No one can judge their own code. We all think we've written great stuff that other people hate working with. Even your team can be bad at judging it, because they can reach out to you if they get stuck. Those are awful ways to judge how good code is.
In my experience the best measure of good, robust, well-written code is the opinion of the team maintaining it a year after you've left. If those people are singing it's praises and happily working on it rather than complaining about tech debt and saying they want to do a rebuild, then you can say you did a good job.
You're confusing a developing thinking their code is well written with a tech team evaluating the value, reliablity and flexibility of a system.
The 'common framework' approach works great if you've solving a common problem. That's why we use libraries for certain modules or functions of a system. When your business is, even just operationally, different in some way, bespoke is often the best way. Make it good and it doesn't matter a sniff if it's an established public framework or not.
> When your business is, even just operationally, different in some way, bespoke is often the best way. Make it good and it doesn't matter a sniff if it's an established public framework or not.
There was a post recently on hackernews talking about how startups have an "innovation limit". That is, if you try to innovate too much, your scope grows beyond your reach. I think the idea applies here as well. Building everything yourself takes a lot of time. If you can position yourself to leverage the advancements of others, you can move much faster.
Absolutely. I am a big force in my place of 'just buy' when others are all 'build everything in house'. If there's no genuine advantage of having something custom then don't do custom, buy something that works.
I'm not talking about back office admin systems. I'm talking about genuine business operations systems. And YES, most are more different than they appear on face value.
I'm not judging my own code. I'm basing my statements off of the results-oriented perspective of the businesses I've helped. And based on their positions in the market, both at the time my team implemented the projects I'm referring to, as well as long after most of us have moved on and the projects are in maintenance mode or retired, I would objectively say we were highly successful.
> I'm basing my statements off of the results-oriented perspective of the businesses
there's different criteria for judging. Business criteria and business success is one (good) criteria, but there's also the criteria of good craftsmanship (which may contribute to business success indirectly by making future maintenance easier). This criteria is hard for a non-technical business stakeholder to judge, but easy for the maintainers.
People often seem to overlook how different businesses operating in the same space can be purely because of a particular specialization or culture.
Custom is best sometimes. And that's ok. A well thought though and implemented 'bespoke' framework (literally just a system) has no value based disadvantage over a public, well known, framework / approach.
No one can judge their own code. We all think we've written great stuff that other people hate working with. Even your team can be bad at judging it, because they can reach out to you if they get stuck. Those are awful ways to judge how good code is.
In my experience the best measure of good, robust, well-written code is the opinion of the team maintaining it a year after you've left. If those people are singing it's praises and happily working on it rather than complaining about tech debt and saying they want to do a rebuild, then you can say you did a good job.