Curiously “my way is the best way” is (IMHO) the greatest cause of problems at the design and architecture level in the Programming World.
I’ve worked for almost 2 decades as a freelance designer-developer (aka contractor) across various industries and even languages and frameworks (all the way from server-side Java to web interfaces and iOS applications) and one quite common scenario was me being hired because some piece of software was pretty much unmaintainable, and that was almost invariably that either a single designer-developer did the whole thing themselves during their oh-so-special learning stage were they’ve just learned software design and overengineer everything (in OO that usually means things such as totally unecessary, all the time, use of design patterns and inheritance for stuff were there is always and only 1 implementer) or 3+ people simultaneously or over the years who each got responsability for that software or part of it and decided “I know best” and proceeded to add a whole new layer with a different software design strategy, coding standard and sometimes even a different language, the result after a few of those being pretty much spaghetti code AND design and some of the most “interesting” bugs you can imagine (due to mismatching assumptions between layers).
By the way, you do notice exactly that kind of crap coming out as APIs and Frameworks from the kind of companies (*cough* Google *cough*) whose idea of Technical Architect is somebody with 8+ years experience and who never worked elsewhere: notice how the Android stuff has had various strategies for doing the same thing over the years, the API has grown over time massivelly (it was already too big and messy to begin with), there’s code-generators in the IDE to try and cover the gaps between newer techniques and older ones and they’ve even introduced a new language half-way for no actual architectural advantage (the pinacle of “I know best” “genious” is making your own language).
Personally during my time as Technical Lead I used to hire people very much based on “have you ever worked on a project over its entire life-cycle?!” because those burned by their own ignorant-yet-pretentious stage are the ones who get it that Ego is less important that pretty much everything else in making software and I firmly believe that “having seen and having had to maintain the results of your own fuckups” should be a requirement for anybody designing an API or Framework.
I am working on a 50 year old codebase which little documentation since “tHe COdE iS tHe ManUaL”…
its in the academic field although this does not mean that people took care about it.
and due to porting to newer language styles this thing is near impossible to get into.
I understand that times have changed much.
however to maintain this stuff progress has to be put on halt until a system is established to clean up this mess of 30 years of spaghetti code (assuming for 20 years it was alright)
Im not even 100% sure that API is really bad? Some hairness could be easily explained by performance reasons. You don’t want logging to take a massive amount of system resources.
The API is bad, I get it. But the author also seems a little too aggressive with the “my way is the best way” attitude.
Curiously “my way is the best way” is (IMHO) the greatest cause of problems at the design and architecture level in the Programming World.
I’ve worked for almost 2 decades as a freelance designer-developer (aka contractor) across various industries and even languages and frameworks (all the way from server-side Java to web interfaces and iOS applications) and one quite common scenario was me being hired because some piece of software was pretty much unmaintainable, and that was almost invariably that either a single designer-developer did the whole thing themselves during their oh-so-special learning stage were they’ve just learned software design and overengineer everything (in OO that usually means things such as totally unecessary, all the time, use of design patterns and inheritance for stuff were there is always and only 1 implementer) or 3+ people simultaneously or over the years who each got responsability for that software or part of it and decided “I know best” and proceeded to add a whole new layer with a different software design strategy, coding standard and sometimes even a different language, the result after a few of those being pretty much spaghetti code AND design and some of the most “interesting” bugs you can imagine (due to mismatching assumptions between layers).
By the way, you do notice exactly that kind of crap coming out as APIs and Frameworks from the kind of companies (*cough* Google *cough*) whose idea of Technical Architect is somebody with 8+ years experience and who never worked elsewhere: notice how the Android stuff has had various strategies for doing the same thing over the years, the API has grown over time massivelly (it was already too big and messy to begin with), there’s code-generators in the IDE to try and cover the gaps between newer techniques and older ones and they’ve even introduced a new language half-way for no actual architectural advantage (the pinacle of “I know best” “genious” is making your own language).
Personally during my time as Technical Lead I used to hire people very much based on “have you ever worked on a project over its entire life-cycle?!” because those burned by their own ignorant-yet-pretentious stage are the ones who get it that Ego is less important that pretty much everything else in making software and I firmly believe that “having seen and having had to maintain the results of your own fuckups” should be a requirement for anybody designing an API or Framework.
well summarized write up.
I am working on a 50 year old codebase which little documentation since “tHe COdE iS tHe ManUaL”…
its in the academic field although this does not mean that people took care about it.
and due to porting to newer language styles this thing is near impossible to get into.
I understand that times have changed much.
however to maintain this stuff progress has to be put on halt until a system is established to clean up this mess of 30 years of spaghetti code (assuming for 20 years it was alright)
Im not even 100% sure that API is really bad? Some hairness could be easily explained by performance reasons. You don’t want logging to take a massive amount of system resources.
Yeah, it is really bad. And lazy. The kind of bad that people who don’t take pride in their work do. The kind of bad that makes great programmers quit