development

On Modern Web Development

by

Tom MacWright wrote a much discussed article on the state of modern web development a couple of weeks ago.

He states that the current default of building a Web Application as a SPA using React, or something similar, in the frontend and an API on the backend is overkill.

This is both an opinionated survey on the current state of web development and an extremely contrarian take on current accepted wisdom on how to build modern web applications. It’s worth a read.

His premise is that we are adding additional levels of abstraction such as Virtual DOMs, Server Side Rendering, Bundle Splitting, etc. He even goes on to say that trying to generic, purely REST-ful APIs is a bit like tilting at windmills, since we end up having them tightly coupled with frontend code anyway.

I am sympathetic to this point of view — mainly because I am rapidly transiting to “grumpy old man” phase of my career, and I find modern web development workflow terrifying complex. I had to work on a React application a couple of years ago. It made me want to run back into the warm embrace of Java Swing development (oh beautiful Java Swing).

The pure beauty of Java Swing

But, I also want to note that software engineering is pretty fashion driven where we bounce around between too much and too little abstraction. Every generation has this battle — Java didn’t have enough features so we ended up with Java EE, Java EE was too bloated so we ended up with Spring, the Java language was too complex so we built Go. Go is missing Generics so we will go ahead and add them. The pendulum keeps swinging and we have a complexity crusade every 5–7 years or so. Unsurprisingly, it has been just about 5 years since React has become the defacto way of building web applications. Time for the backlash!

I am sure we are going to be back at folks writing pure HTML and FTP-ing to an Apache server day now 😉

Code of conduct for Professional Programmers

by

Robert Martin’s book Clean Code (Amazon Link here ) is one of the most important books I have read on the craft of software development. It is a language / platform agnostic book on how to write good, maintainable, and readable (i.e. the “Clean”) code.  But, when deadlines start slipping and things start falling apart, it is all too easy to cut a few corners and accrue some technical debt which will come due later.  It looks like Robert Martin has written a follow-up to Clean Code. The title is The Clean Coder: A Code of Conduct for Professional Programmers (Amazon Link here ).  It is on my “to-read” list, but Christoffer has written an excellent summary here.  He lists 9 points that he took away from the book. For me the most important point was this:

A Professional Programmer Takes Responsibility

It is very easy to blame the BA (Business Analyst) for not writing a clear specification or a clear test plan. It is easy to blame the user for not doing a thorough UAT, and it is easy to blame the QA team for not doing integration testing properly. If there is a bug in the code, it is the programmer’s responsibility. Once a system reaches a certain complexity, there will always be bugs or edge cases that somehow slipped through into production. Once a bug has been identified, it is the programmers responsibility to explain it, to fix it and to ensure that similar mistakes don’t happen again.

I have been (and routinely am) in positions where a bug in code I have written has lead to a significant outage or a measurable, significant, monetary loss. The first instinct is to always look for problems somewhere else. Maybe something went wrong in the operating system, maybe the deployment team did not release the packages correctly.. It may be the case, but as a Professional my first responsibility is to check my own code. What did I change? What could have gone wrong? How can I reproduce this error in the test environment? How do I fix it? And finally.. how do I make sure this does not happen again?

In my experience, a policy of complete transparency is the best policy for a Professional Programmer. If the management team knows they can trust you, they will generally be more understanding when things fall apart in production!