- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
TRWTF is that the customers with red backgrounds are not defined in an XML file which is read and processed each time the page is rendered, yes?
Admin
This is bringing me flashbacks to my first developer job (in 2018, hardly ancient history). Pretty sure it wasn't this company (they provided an online education platform, not document management), but they had exactly this - lots of if statements checking for hardcoded customer Ids. It was far from the worst spaghetti in the codebase, but it says something when after a few weeks you know the Ids of the biggest customers (the ones who make lots of special requests that you can't say no to as they bring in a huge proportion of your company's revenue) off by heart!
(I did hear that a big rewrite of the whole platform was in progress so hopefully that's all gone by now - but I'd seen sense and left before that got started!)
Admin
Yep, this is not at all unusual. Once place I worked had the same problem: so many customer-specific code paths that they eventually started trampling on each other, and a change for one customer had a high probability of breaking someone else. It got so bad that they had to completely refactor the code, and even the dev team itself, into a core + plugins model in which all customer-specific features were isolated in customer-specific plugins until such time that the architects deemed the feature common enough to move into the core.
I've also seen the opposite extreme: every single aspect of a web app controlled by a feature flag, right down to individual CRUD permissions on each page. So customers had hundreds upon hundreds of "features" to choose from when setting up every single user, with the available features for a customer determined by licenses. Meaning that, if you were a developer and wanted to test a particular page, you'd better make sure your test setup had all the right licenses and features turned on or you'd be in for a good several hours of frustration.
Admin
Now just imagine (the surely non-existent) test suite which covers all of the permutations (i.e. is cyclomatically complete over the codebase)
Admin
I'm not gonna pay for red cells, I'm just gonna implement that in a Greasemonkey script for free instead. Take that!
Admin
Repeat after me: Configuration file. Configuration file. Configuration file.
Admin
"...plan for changes before you even know what changes you need to make"
You've hit the nail on the head. As Niels Bohr said "Prediction is very difficult, especially if it’s about the future". Time and experience has taught me the YAGNI principle is usually the most appropriate. The first few times you have to do a special case (if you really can't find a design that works for all) , a conditional is fine, even if it is for customerId. Once a pattern emerges and it becomes easier to have a system of plug-ins, adapters, configuration files whatever, then you implement that. If you go in thinking "we're just going to make everything configurable" you're making a world of pain for yourself and I guarantee the first tweak a customer wants will be something you never thought of.
Admin
The major WTF here is not creating constants for those customer id because the instant you do something like this as a developer you should realize its only a matter of time before something gets escalated to you to the effect of "ACME corp says blahblabh is broken but nobody can reproduce and no other clients are reporting issues."
How WTFy this type of thing overall really depends. There is a certainly a range of industry specific software products where you might have to customize it to make a sale, especially to larger client. There are times when they are asking for something your really don't want to have to support for other clients because it simply does not reconcile with some other feature/workflow, and client A understands that and signs off but if you make it a parameter its inviting some other sales to go an try to use it with client F who did not agree to the consequences. Sometimes a few client specific versions of a normally common procedure really is the least complicated path forward. However I'd certainly rather see that stuff implemented as conditional build options rather than stuff that survives to runtime; however that is a harder in a multi-tenant SAAS/PAAS setting.
Admin
I had a similar experience. Our nearest competitor managed to do it completely wrong: Different code sets for different customers, which meant any actual bug or feature had to be applied across, I don't know, several or dozens of code sets.
We went the feature-flag path, which was much easier. Dozens of features each controlled by a flag, but at least it was usually only a small chunk of code affected by the flag, and we only had one set of code.
Admin
Been there, done that, and it isn't always that bad.
Sure, ideally you'd store information like that in a database, but schema changes are relative expensive, and cleanup of unused schema parts are even more rare than removal of dead code. If I were to get a change request like that ("do one specific thing, for one specific customer") I may consider hard coding a customer id as well. Spending resources building a more general solution can be postponed until it becomes clear we need to do this for more customers.
Part to the real art of software development is knowing when not to do something.
Admin
"building a more general solution can be postponed
until..." AIR HORNAdmin
"building a more general solution can be postponed
until..." AIR HORNAdmin
Unfortunately, this is pretty common. Especially in startups with big potential customers who want some non-standard feature in order to sign the contract. And this code tends to remain when the company is no longer a startup...
Admin
An alternative to YAGNI is to focus on Scott Meyers "Minimal yet Complete". Doing "something simple now, KNOWING it will cost you more later" is the very definition of Technical Debt. While there are certainly places where TD makes sense, it needs to be carefully weighted lest the interest bankrupt you.
Admin
So familiar. I had to maintain a website where hard coded user IDs provided security. When it was getting obvious as the system grew larger and more complex that classes of users were needed, categories were added to the web config file (as DrPepper suggests). But the old numbers weren't refactored out. When the config file became unwieldy, bit fields were added to the user information in the database. This was better and a security page was added. Unfortunately, the previous two systems were left as is. But a database change and security page change got unwieldy, too. So a security code table was added and the security page got a flexible table entry for that. But the 3 previous systems were left in place. Four completely separate security systems in one website. Oh, and the javascript occasionally borrowed from a couple of those. What a mess.
Admin
Did that place happen to be in the field of 3D printing?
Admin
Let's just hope that the actual data populating those cells is defined in an XML file.
Admin
Or you just give up and install a 'Business Rules Management System', so that your software no longer needs to know anything about this, you simply let the BRMS tell it what needs to happen at any given time :)
Admin
I just boil it down to WE3. Write everything thrice. The first time, you have your baseline case. The second time, it looks tempting to optimize - don't. The third time, you know what is actually your common case and what should be feature flags, and what should be overly-specific conditionals.
Admin
In my opinion nowadays business more and depends on tehnology, thus i fully know that many try to implement blockchain technology. We even have games with cryptocurrence and this is quite fascinating as people can become some sort of businessmen by just playing games and develop their character for sale. Let's not also forget about huge NFT-market which evolved alongside blockchain technology, so i think in future thus tendency will keep growing and become stronger and stronger
Addendum 2023-01-10 10:11: In my opinion nowadays business more and depends on tehnology, thus i fully know that many try to implement blockchain technology. We even have games with cryptocurrency Go to Play To Earn and this is quite fascinating as people can become some sort of businessmen by just playing games and develop their character for sale. Let's not also forget about huge NFT-market which evolved alongside blockchain technology, so i think in future thus tendency will keep growing and become stronger and stronger
Admin
wow
Addendum 2023-04-10 10:07: google.com google [url:google|https://google.com/] [url label="google"]https://google.com/"]google[/url] [link:https://google.com/ | google] [link:https://google.com/ google] [link url=https://google.com/]google[/link] [https://google.com/ google] google.com [[https://google.com/ google]] google [L=https://google.com/]google[/L] google.com "google":https://google.com/ moving image
more information from https://google.com/
Addendum 2023-04-10 10:10: Understanding customer needs is essential for any business to thrive. By identifying what customers want and need, businesses can tailor their products and services to meet those needs and provide an exceptional customer experience. ICOholder is a great resource for businesses looking to stay ahead of customer needs and trends, providing valuable insights into the latest developments in various industries. By leveraging resources like ICOholder, businesses can stay informed and adapt to changing customer needs, positioning themselves for success in the long term