257
"Code was never the hard part" is an insult to all programmers
(blog.senko.net)
This is a most excellent place for technology news and articles.
The interesting thing, to me, is how much/little architectural level design matters depending on the complexity of the system you have built, and the longevity of its maintenance in the field.
I watch things get built with bad architectural compromises for what appear to be bad reasons all the time, and they rarely "come home to roost" until years later... then the question becomes: was the implemented design a success for having gotten to market quicker and lasted so long without serious problems, or a failure for having created a mess 5 years down the road that could have been addressed with a 5 day delay of launch for a refactoring? Or, should we instead spend 5 weeks attempting to predict the optimal architecture before we even start and maybe get a good solution or maybe still end up learning things we didn't know during early development - and when we learn those things down the line from the initial architecture specification, when it it time to slaughter the sacred cow and re-arrange things?
Oh, they "come home to roost" almost immediately - you just don't see it because whole teams are doing everything they can to hide it or ignore it - nightly manual data update statements, etc.. Here's just one real example.
In my last (read: final) job as a senior software engineer, I discovered dozens of serious problems with the system I was assigned to "maintain". They ignored all of them - wouldn't let me fix anything. Meanwhile I was responsible to solve production problems on the daily (duplicate data, insert failures, performance slow-downs, etc).
It wasn't long before the fact those problems weren't going away that they became problems I "caused". Meanwhile, all the fixes I wanted to make were ignored. I had one problem I dissected and and gave my boss a brief write-up of the scenario. He told me I needed to do deeper analysis. When I came back a few hours later with a considerably more detailed explanation, he didn't read it and complained of a "wall of text", which he literally told me to write. Then he created a random-number hack to "fix" the problem.
They did not grasp the concept of data normalization and primary keys as they had one particular table that represented two levels of detail (for example, account -> order). They put both in one table and had a code based special update to the "account" number so they would not get a PK violation rather than just fix the data structure.
They had as single database connection open all the time to handle all inserts in a singleton service, then launched as second one on the same database to process messages faster - and couldn't understand why it didn't double performance.
The main routine had a cyclomatic complexity of 360! I shit you not! And everybody agreed it was "95% working" even as we continued manually fixing (the same) problems daily.
Week after week, the customer (internal) would raise more data issues as "new" problems. I'd routinely ask two to three questions about the data set and explain that's the same problem that's been going on for six months, and if we could just get my PR reviewed, we can test it and deploy it.
All these problems were in a single service.
I was let go not long after the 1 month probation they soon initiated and told I was not performing at the level of a senior developer.
This is how delusional these people are. They refuse to acknowledge their flaws even after hiring someone specifically to solve them. They blithely call their monstrosities "successful" while committing many staff to late nights and weekends "managing" it.