Paul Cowan Contract software developer

Developer frustrations in 2020

3 min read 1074

developer frustrations of 2020

Disclaimer: This post is tongue-in-cheek and meant to be a lighthearted poke at current development. Please do not take this post too seriously.

We developers love a good moan. We are drowning in free open source tooling that we can install and discard in seconds. We care not for the midnight oil burned by selfless open source maintainers who sacrifice their free time to make our lives easier. We complain about it, mock, and moan. We have easy jobs that provide us with a higher-than-average standard of living. Does this stop us from moaning? Does it heck! I’m now going to put the world to rights with my top moans of 2020.

Agile is now spelled scrum

Scrum has ended agile and is doing a very poor impersonation in its place.

The tenants of agile used to be this:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I have worked on several contracts recently, and agile 2.0 now looks like this:

  • Two-week “commitments” are made by the people who are not doing the work
  • Ticketing systems over working software
  • Soulless planning sessions turn farcical as meaningless numbers or story points act as a pathetic attempt to disguise hard dates that senior management needs you to give. Words like ‘estimate’ pull the unaware into a spider’s web of accountability where mythical story points become hard dates that you have not met. Hang your head in shame, the scrum burndown chart does not forgive you

Retro to the last retro

If you have ever sat through an agile 2.0 retro, then you will have stuck some post-its into three imaginary swim lanes with names like:

  • Stop
  • Continue
  • Start

You will have placed garbled scrawls on wasted post-its with barely legible hieroglyphics that state the same message as they did last time:

  • Good teamwork
  • Too many meetings
  • The build takes too long
  • Tickets are not well defined

Why do we not just reuse the post-its and be more eco-friendly?

You will continue to do this until the world stops turning because agile 2.0 is not about adapting; it is about doing the same thing over and over.

Things do not get any easier, they just get different

I am 50 years old and have been a developer for longer than I care to mention. In this time, I have learned 679 ways to render HTML. At least once or twice a year, I learn a new way to render HTML and at least 2.3 frameworks to help me on this journey.

As the big hand of the clock turns onto 2021, server-side rendering is suddenly the new kid on the block. The single-page application is as gone as a dodo.

We made a custom demo for .
No really. Click here to check it out.

For the past seven years at a guess, it was considered heresy to render HTML on the server. Client-side rendering is the work of the just and good. If you care about your clients, then do not offend them with your prehistoric server-side rendered application. Open their eyes to the new religion of browser rendered applications with endless spinners illuminating a path to three megabytes of JavaScript force fed to your bloated and choking browser.

Well, hold the front page, something big is taking place. My Twitter feed is alerting me to a new happening. The pendulum of justice has just shockingly sprung back to readdress the balance. Server-side rendered HTML is championed as a new beginning. It is a clean slate, a new page, or a new frontier of ingenuity. Endless new paradigms are now possible. I am frantically trying to find my “ASP for dummies” book that I knew would come in useful. Those old tricks will still be relevant today. The more things change, the more they stay the same. It is now time for the PHP developers to take front and center page. It is time to tell all those suddenly uncool JavaScript developers that they have been wasting their time. If we fast forward seven years, the client-side rendered application will be in vogue again.

Bundlers

I seem to be learning about 1.2 bundlers per calendar year. Every bundler has the same goal in mind but is ever so slightly different than the last.

In Vietnam, they have a saying:

Same, same but different.

The above great saying instantly makes me think of development, where I continually learn new and cunning ways of achieving the very thing I first learned twenty years ago.

At one point when Ruby was cool, we all got a tattoo on our foreheads that stated “convention over configuration.” Revolution was in the air, and the old tired ways were replaced with the new. As is customary in development, the new methods have now been replaced with the old. Large sprawling XML files have been replaced with large sprawling JSON or YAML files that are of course ergonomically better.

Bundler configuration has replaced “convention over configuration” with “endless configuration over your sanity”. You will need to specify every iota of every single transform if you want your six-megabyte bundle which you spent six weeks code splitting and tree shaking to impress your peers and bankrupt your client. A major version bump of one of the leading bundlers can derail even the best agile project as you come to terms with the carpet being pulled out from under you as the ten thousand lines of configuration are now worthless and will need to be rewritten from top to bottom.

Why are we still writing so much code?

Is it just me or are we writing considerably more code that spans many different invisible boundaries of complexity? There was a tale that artificial intelligence would replace developers, and a business analyst would speak into a smart computer describing what the application should do, and out would pop a shrink-wrapped web application ready for production use.

The needle has hardly moved, and here we are typing as fast as our bruised fingers will let us as we hurry to meet the imaginary SCRUM story points that are after all “only estimates” and not let the team down.

Epilogue

My review of 2020 is now complete. What a shockingly similar year it was to 2019 in a development sense.

Now let us raise a glass and toast the new era of doing exactly the same thing only in an ever so slightly different way in 2021. I, for one, cannot wait.

Happy New Year!

Same, same… but different.

: Full visibility into your web apps

LogRocket is a frontend application monitoring solution that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page apps.

.
Paul Cowan Contract software developer

2 Replies to “Developer frustrations in 2020”

  1. Very good points coverded here. The JS world seem not be content with anything they do, they think that by adding new stuff every week it may seem to them they are progressing when in fact are not solving anything at all, just more of the same, reinventing the same wheel ovee and over. Im hapy to see now things like laravel livewire which was inspired by phoenix liveview, i hope to see this trend more and more and do less JS which is more complication than actually solving a problem, it has its uses but they have the wrong view to try to force that for everything and talking down any other development approach as outdated or wrong. It is funny how much they struggled with ssr these years and still is a problem for apps that need an online presence, which is almost every app these days

Leave a Reply