Very funny thing happened at this other fictional tech company called SomeCrazyTechCompany LLC. The project manager and business analysts always sat down and discussed requirements, as well as client changes. As usual, the client wanted more features, and as usual, the BAs obliged.
One day, the developer who worked on the system quit, and the company hired another poor soul to take over. Everything went as you would expect. The developer struggled heavily to maintain the system. Let's not talk about bugs, and more requests for features.
A friend of mine seems to have the same issue. Her problem is not the client; in fact, I could say she is the problem. Clients always request more features and changes, but in this case, she's the one who more or less asks the developers to make the changes without consulting with the client. And also add more features. And as you would expect, once the system goes into production, it's a mess of bugs and more bugs... and even more bugs.
For a small system, it's very easy to maintain, discover bugs, and test thoroughly. However, as the system becomes larger and larger, it becomes more difficult and time consuming, to test thoroughly. So, most people usually check to see if it's working, and then update the feature/bug card on the project management tool. However, the issue is, a few minutes later, the same problem will resurface. Or even worse, something will explode ... and it will be related to this problem.
Unfortunately, as much as it might be great to make a small system, it's very much impossible to keep the system small. What I'm saying is, due to some unfortunate circumstances, that have absolutely nothing to do with the scope of the article, everything will explode at some point.
There's a wise dude who once said, where there's a possibility of things going wrong, they will go wrong. He was right. And this can be seen in the Software Development sector. If there's a chance that your system will explode, then everything will go haywire. If it's a smaller system, then it's easier to manage. What about when it's a giganticous (not a real word, I know) monolith? Good luck.
That brings me to something else. Solutions to this issue, if there are any.
A group of people realized that having a large system was a recipe for disaster, or a disaster waiting to happen, or something worse. Being as clever as they are, they decided to break their system into multiple smaller systems. Someone went so far as to give it a name: Microservices Architecture. It was awesome, because if something breaks, you know exactly what broke, possibly why it broke, when it broke, and very much possibly how it broke. It would take a few minutes to fix it, if you're that good. And a few years, if you aren't.
The problem with this approach, since everything has a problem at some point, is that when you have 200 small systems to maintain, and there's only one of you, how do you do it? Or maybe there's 2 of you ... or 5 ... either way, how do you do it? Do you go and clone yourself and then assign your clones to maintain the systems?
Well, I just thought I should put it out there for people to think about, if they weren't already thinking about it. Next time your client wants you to create another feature, make sure you know exactly what problems you'll encounter. Once you've managed to somehow do it, make sure you test thoroughly, whatever that means. And make sure to cover all angles, including the ones you think don't matter. When you've exhausted all possibilities, then you should know that once the monster is in production, you might have issues maintaining it a few months from now (if you're lucky). If you're very unlucky, the monster will blow up the moment it hits production, and the users start using the system.
Life's great. Bugs aren't. So, before you develop more of those, or ask someone to, think twice or three times. Or four, just for good measure.
Top comments (0)