1. Give all your Python class members a tedious naming convention.
2. Be DRY by writing helper functions that do name lookup based on a string of the last half of the member name.
3. Be even more DRY by having the function guess a little if the match isn’t exact
You now have an application where you cannot search for where members are referenced.
Clean Code was mental poison for me and certainly led to a bunch of overly abstracted or overly-DRY code.
Sometimes repetition is good.
For some reason everyone tried to be clever with code reuse in them which almost always resulted in an unsearchable mess.
At that point you'll be singing How DRY I Am!
I noticed a variable (long word starting with z) used in a lot of places. Turns out it was the German word for "counter".
It was my first hint that most of the backend codebase was written as a competition between the two of them to seem the smartest.
On the front-end, I remember opening some many thousand line long file trying to figure it out. I scrolled pages and pages to the top of the file looking for a comment. I found one. The comment:
/* What is this shit? */
Written by someone who tried to help those guys.
1. Get an n year government contract for some huge public IT overhaul. E.g building a new hospital journal system for a large region(this example is real, google "helseplatformen")
2. Spend years developing this huge proprietary .net monolith with a waterfall model, and minimal user interaction and testing during most of the contract.
3. Release an MVP by the end of the contract that's barely suited for the task(inevitable due to inherently broken dev model) and causes a huge amount of problems
4. Get another n year contract to fix the thing
5. Print money.
But seriously, I guess it depends on the maturity of those writing the tender / anbud. Too often they get bamboozled by big4 like consultancies (Accenture, Sopra Steria etc..) that act more like project managers and sales people than developers.
The company I used to work for actually stopped giving offers on lots of these kind of projects. None of us wanted to work on these kind of bureaucratic nightmares where one is set up to fail. It's much more fun to deliver something of value, even if one doing something else could've squeezed out some more money. We "fired" clients that didn't give us opportunity to actually do good or have an impact.
I think more of these public sector tenders should stop focusing on "projects", and instead focusing on just getting the correct people that can help them iteratively move in the correct direction.
Unfortunately it's often hard to get money for this. Easier to say "we need X millions for this huge project".
I wholly agree with you that big projects are not the way to go. I think a push towards open source would greatly improve accountability. And I don't see why say the tax reporting system needs to be proprietary besides a thin veil of security through obscurity.
The bigger an organization is, the more easy money they have, the worst their expectations are when it comes to software development. I once worked for such a company as a software developer and I was shocked that I kept getting positive reviews in spite of being the laziest I had ever been. I was spending most of my time watching videos on YouTube; but the little work I did between YouTube videos was somehow better than that of their average employee...
Then even if you get such contract you probably stop being efficient - because of red tape and lack of incentives to still be efficient because money will flow either you are efficient or not.
The tender requirements were written by a general tender-writing team of the government.
We only got to meet the actual users of the software-to-build after we'd won the tender. Apparently what was in the tender was a complete mismatch with what the actual users wanted (as far as they actually knew what they wanted).
What the users wanted didn't matter, because payment was based on checking off all tender requirements. Oh, one of the tender requirements was "all business logic needs to be configurable by the users" and more gems like that.
When you get most of daily contractor fees directly, you easily end up with 15,000k$ net monthly income, working mostly remotely, in a country that had median monthly income below 1,000$.
Not that he worked hard or anything, frequently fridays looked like 'ok I am free give me some work' which almost never came. It was done on some ancient long dead weblogic/wslt things, stuff I can hack together in ie apache camel or similar in few afternoons (not 100% of it but core definitely yes).
Definitely a fault of government, no private company will come and say 'hey we can do it in 10% of the time / costs but we wont be using these big brand technologies (TM)'. Can't imagine there wasnt some big corruption too. IIRC prod launch was some major clusterfuck which filled newspapers for some time.
At least here in Norway, a huge part I think is that the buyer doesn't have a good grip on what they need. The people making writing the bids or managing the projects are too far removed from the day-to-day operation to write down proper requirements.
Don't get me wrong, it's hard. But for these large projects I think many would have gone a whole lot better if the buyer had spent more time understanding their own organization and their needs before doing these large projects.
You want names that do describe your code but badly. If your function reads policies from the DB, filters them and calculates some missing data, be sure to name the function 'readPolicies'. Nobody will look at that function when chasing a bug related to the filtering part!
You may want to spread it across a few changes to get plausible deniability. You may also "fix" the name by changing it to something hopelessly generic like `initializeState`.
Use micro-services! The more the better! And write each micro-service using a different programming language and build system. Make sure the protocols are not documented. And that the micro-services are called p376, f190 etc. Make sure that some micro-services need to access a specific server setup to build!
So I would say: find the most obscure place you can deploy code, and make sure it is not testable.
What I saw there in particular was that any given team will try to solve their problems in their domain. For example, I was in the database administrator team, and they tried to do everything in the database and use database features for everything. Then you have the DevOps/Middleware team who try to do everything in pipelines and with ansible scripts etc.
The best thing you could invest in imo. to be a good allrounder is really good knowledge of unix(like) systems and a shell which is available everywhere.
Write your cicd pipeline logic as shell scripts instead of e.g. the dsl of gitlab/github. That'll be usable in every domain!
I can't stop laughing.
m_bIsLaughing
There should be more tips, like use "l" as a prefix to any number, like shorts. Also, make sure to sometimes distinguish shorts, ints and sometimes not!Also, when you've accumulated about ten years of this, start using a different making scheme and make sure there are preferably random bits of Hungarian notation around. Make sure there's no record of why and no explanation of what Hungarian notation is and how to use it.
Often these were crazy code forking paths like:
* a is a 1 liner which calls a_ or aa depending on a conditional.
* a_ then returns something or calls a__ depending on a conditional.
* aa calls aa_ or aa__ depending..
* A, AA, A_ and AA__ might be some global states or boolean flags or cmdline args or env vars read in which effect all the above..
Another favorite was to use the same noun in different cases for different types of things. For example:
* servers - a function you call which returns a list of servers
* servers_ - a subfunction called by servers
* SERVERS - a boolean global variable switch to enable functionality
* Servers - a variable containing the list of servers used by all of the above
I once asked him to explain the differences and there was no consistency. Sometimes all-caps was the function, sometimes all-caps was the boolean, sometimes lowercase, whatever.
The best was clearly someone forced him to put in comments under duress.
However he ONLY commented the obvious stuff, like-
getCmdline # gets the cmdline
My friends, it’s time we all learn regex. You’ve heard it’s unknowable, but a simple \b on either side of your target search is your friend too! It just means “there isn’t an alphanumeric character next to me!” It wants to get to know you! If you can’t search for a variable named a, it wants to help!
Code like that should set off alarms very fast, and any code review should catch it early on.
if (article > 0)
confusing early on becuase you would start thinking this is a beginning of arithmetic comparison of numbers when it actually was just a check if the article existed or not.< Sir Alec Guinness voice > That’s a name I’ve not heard in a long time…