Instant legacy

 

Quick throwback

I have been writing code for a long time. I've been through thick and thin, even before "the internet" and I was rewriting code from paper books. Yeaaa, I've done some things I'm not proud of. Things back then went slow, we waited for Microsoft to come with an update for Visual Basic 5 so I can use my modem from code to call my friends from THE COMPUTER. All was peachy, no sudden changes, no paradigm shifting, OOP was just making a mainstream break through. I'm saying, existing developers were happy.

These days

There are ten different frameworks for even the smallest of tasks... Hell, a new JS frameworks is popping up every 6 Months. New kids on the block don't even know what an object is these days. Functional programming is making a come back and everybody is constantly letting arrows -> -> -> (nerd jargon, sorry I had to)

Should we keep up with the trends

Not with the minor updates, but surely consider the major paradigm shifts. And this is not only my opinion, this has been a debate in our circles for a long time. A new shiny and well advertised JS framework is not a reason to cause an earthquake on your project and team. However, as a good Software Architect, one should foresee the trending and adjust team's mindset to easily accommodate the major paradigm shift when they inevitably happen. 

There are several common pitfalls at this day and age, that lead to writing what we call Instant Legacy Code:

  1. Thinking of the project as one unit of matter, instead of small pieces of service bricks
  2. Thinking of your team as machine, that only needs attention when it breaks
  3. Not thinking about Unit or Automated testing
  4. Not thinking about CD/CI, doing everything manually
  5. Not having coding standards, If it does the job, just keep going!
  6. Not using well known code stack or language standard frameworks/libraries
  7. Not thinking about containerization, scalability, etc...
  8. Not thinking about caching and security
  9. Not optimizing during development
If any or more of these points are lingering on our setup, we are writing instant legacy code. 
No client will pay for you to refactor the code so its more readable, that concerns developers only. Clients want to see features, they pay for availability, response times, they don't care if your application is compatible with Docker. They will just ask why the application is difficult to maintain or scale. Its our job to comply with the world of technology!

To sum things up, change is great, its our job to make it smooth!

Comments

Post a Comment

Popular posts from this blog

Its not a bug, its a feature

Image
  I was always a little odd kid, compared to the rest of the children in my surrounding, that is. When all the kids were chasing the empty can they found on the street pretending to play "football", I was looking at how that exact can bounces of the curb, admiring the symmetry of the collision angles. I was fascinated by the intricacies of the bouncing trajectories, from the simple act of playing marbles to the mesmerizing chaos that unfolds as balls disperse across pool tables.  Long story short, I was the strange kid in the bunch. That impostor syndrome persisted in me for a long time through high school and college, just the topics changed. I was always considering it a bug, part of my non-fitting-in character.  What I realized growing up, was that a small perception shift can change my bugs into features. The paradigm shift was: What if I can use a given peculiar quirk of mine into a skill I can get a value from. I don't mean like business point value, I mean more lik...
Read more

The Ship of Theseus

Image
There are two approaches of buying tools and supplies, JIT and hoarding. My father had the JIT (Just In Time) system in place. Being a weekend warrior, he would buy the tools and supplies for the weekend project during the week, anticipating the work on Sunday. Him being raised in the 60s, he never over-consumes, if he needs a drill, he would buy a drill, not the whole set on discount (with useless tools), just the drill. Same went for drill bits, if the job required a 6mm drill bit, he would buy just one, use it, never sharpen it, and throw it at the bottom of the tool box.  Early on, having inherited some of his tools, I also adopted this JIT system of working. However, as I was enduring in more weekend projects, I realized that often times I needed multiple tools at the same time. Further more, it's difficult to predict which tools one would need in advance, especially considering my lack of experience at that time. So I often opted for improvisation, if I needed a 5mm whole, I ...
Read more

In nomine patris et matris et sancte vehiculum

Image
  I am not a superstitious, nor an excessive believer in the divine,  however my last experience with our savior, I would only describe as holy.  Reflecting on our last ski trip to the Austrian Alps, despite our accommodation being relatively close to the ski center, we opted to drive due to my aversion to shuttle services. Anticipating the trip with my usual anxiousness, I meticulously packed our gear the evening before and ensured all necessities were in order. The weather forecast wasn't a concern for me; after all, we were prepared for the cold in the snowy mountains. Little did I know, this nonchalant attitude would come back to haunt us.  Early morning, all prepared, we got in the car and started driving. Considering this was my first time in this ski center, I was hesitant about overcrowded parking lots and having to drag the skies for a distance. I hate that, it have happened to me several times and it's an agony to say the least, cranky children don't help t...
Read more