Over $85 billion spent on fixing bad code [bootcamps, junior devs, JavaScript, and software design principles]

I came across an article recently from CNBC titled Tech's ultimate success: Software developers are now more valuable to companies than money. They summarized a few really important details that I think are relevant to us today.

A majority of companies say lack of access to software developers is a bigger threat to success than lack of access to capital.

Truly, it’s a great time to be a software developer. We’re in demand. We’re essential to the success of a mass majority of companies. The fact is: nearly every company is a software company. And every company needs good developers.

Still, companies are misusing their most important resource, with too many developers tied up in projects designed to prop up legacy systems and bad software, at a cost of $300 billion a year — $85 billion just dealing with bad code. Correctly deployed, the expertise of software developers could add $3 trillion to global GDP over the next decade. - CNBC (6 Sept. 2018)

$85 billion. That’s a lot of money spent on maintaining bad software.

Think about if you hired someone to build your house. You would hope that for what you pay, you get what you’re paying for. You'd also assume that you get the job done well, right?

Building a house is not much different than building an application in principle.

We need to pay just as much attention to the structure and the details (or Policy and Details with respect to code). Failing to do that, we could end up with something very expensive to fix.

Bad situations like that can really hurt (and sometimes end) companies. It's time we realize that we're software craftspeople.

Yes, it is important that we know how the tools work and how we can use them together. It’s also just as important that we have a strong set of software design principles. A professional code of quality. Something that we can refer back to will help us understand potentially bad (and expensive) code from good code.

Principles > methodologies

Let's back it up a little bit.

Where does all this bad code come from?

I think there are a variety of reasons why we’re dealing with this as an industry now.

JavaScript is the superhero that it never wanted to be

JavaScript has quickly become the most popular programming language on the planet. JavaScript itself, and the community are amazing.

What initially drew me to JavaScript years ago was the fact that you could not only create useful software, but you could create interesting web experiences. From web apps to desktop apps, mobile apps, backends, serverless functions, graphics, AR/VR, digital audio processing, artificial intelligence, etc. JS has quickly become one of the most sought after skills for developers entering the industry.

But also, in the most lovable way possible...

JavaScript is also kinda frankenstein.

Not only do JavaScript developers have to deal with the waltz of supporting non-modern browsers, but they've also had to deal with the language going through various syntax extensions, flavours, and the rise of necessary build / transpiling tools (hint hint, TypeScript), and frameworks.

It’s a necessary strife though, because no one saw how important JavaScript was going to be.

JavaScript is fun and the barrier to entry is low for Junior Developers

Despite the mess, JavaScript is fun and producing something initially with JavaScript is a lot easier, thanks to the community ❤️ and the ecosystem.

I think that’s why a lot of junior developers (myself included, at one time) flock to it.

I don't know about you but I hated Java in school. Red lines in my NetBeans and constantly being unable to progress to the next lines of code because the types were wrong pissed me off.

I hated that I had to define the type for everything. I hated the concept of generics and the fact that everything had to be a class. It made no sense to me. It was very annoying for someone starting out.

When I discovered JavaScript and the fact that you could make generative art, music, and a myriad of other interesting web experiences in JS just using functions, I said "forget classes" and went fully in on JavaScript.

I was able to achieve a level of dexterity with JavaScript that I was never able to achieve with Java, way faster than I could have imagined.

When I picked up my first JavaScript book from Scotch.io titled “The MEAN Stack”, I flew through it.

Following the code examples, I was amazed that I was now able to build a full-stack web app.

“I’m a full-stack developer.” That’s what I began telling myself and everyone around me.

It wasn’t until much later in the future when I worked on large 120k+ line Node.js projects and even larger React.js ones (compiled without Types) that I realized there might have been a reason why Java was so hard.

I was missing essential software development & design principles.

Because I didn’t spend any time honing that, I made a lot of expensive messes when I got put on real-life projects.

Bootcamps and schools are ushering developers out into the industry with a lack of design principles

Coding bootcamps have become really popular recently. They're arming their graduates with the skills in order to write code that will work.

Unfortunately, some schools and bootcamps are failing to equip its graduates with best practices and design principles towards writing maintainable and flexible code.

I think part of the reason this is happening is because developers are learning loosely typed languages like JavaScript, and some aspects of writing clean SOLID code, like Interface Segregation Principle are actually straight-up impossible with this language.

For front-end developers, I think we can get away without this.

But for anyone working with Node.js on the backend, I'd say knowing your SOLID principles are a hard requirement.

Another bold statement to make is that if we understand the principles, we can vet new trends in the industry and make educated software design choices for ourselves.

For example, there's a lot of hype around React Hooks and their utility.

• via Tyler Mcginnis

Business are concerned with exactly two things:

Making money and saving money

The ability to write code that is performant, clean, and able to be changed is so incredibly valuable to a business.

If we're writing code that is going to hard or impossible to be changed, then we're doing neither of those two things.

A lot of companies talk about Agile Software Development and say they practice it. Well, flexibility is actually one of the primary requirements to doing Agile well.

Agile requires fundamental software design skills

If you’re not familiar with Agile, it’s an alternative approach to developing software that fosters iterative improvements to code and detests a fully-fledged up-front design. The contrasting approach is Waterfall where you define everything upfront and stick to the script.

The main reason why Agile is such an attractive approach is because the iteration cycles are smaller.

Because of this, we can adapt to changes in project requirements (you can be 99.99% sure the requirements will be bound to change at some point).

Here are a few principles of Agile Software Development.

• Deliver customer satisfaction by delivering valuable software continuously
• Always accept change of requirements no matter how early or late in the project
• Deliver software that works within a shorter timescale
• Working software is the key measure of progress
• The agile process promotes sustainable development
• Continuous attention to excellence and quality in technical development and design boosts the agility

from luis-goncalves.com

So it's apparent that knowing how to write maintainable and flexible code is incredibly important.

Check.

Makes sense. If you're a developer in 2019, you'll be doing Agile at some point. And if we're doing Agile, we can fully expect that the code is going to be going through a whole lot of changes and improvements.

What do we call that in software development? The process of improving existing code? Refactoring, right?

The thing about refactoring code is that it’s incredibly risky if we don’t have tests.

You cannot refactor without a comprehensive suite of tests that you trust with your life. If you have that suite, refactoring is always easy and free of risk. A moment of refactoring becomes a trivial thing rather than a huge risk.

— Uncle Bob Martin (@unclebobmartin) June 2, 2019

Which leads me to my next observation.

Developers struggle with writing tests

In a lot of Agile projects, tests don’t get written at all. I know this because I’ve been that developer not writing tests.

I believe this is largely because a) developers are under a time constraint to meet the sprint, and don’t have time to write tests afterwards, and b) a lot of developers haven’t actually been trained how to write testable code.

As Uncle Bob said, the blaring problem is that when no tests get written, it becomes incredibly risky to refactor code later to add new features.

It's even more risky if the new features’ use cases cut through existing features. This can lead to a number of problems such as:

• large bodies of code that everyone is afraid to change
• a lack of encapsulation / anemic domain models
• non DRY code / repeated code (“helper” files and folders)

In Michael Feather’s book about dealing with Legacy Code, he says:

“Legacy code is code without tests”.

So let's put that to bed. It is risky as hell to change code without tests.

TDD (Test-Driven Development)

One of the most controversial trends to hit the industry has been TDD. It’s worked for some, and failed for many others. But the reason I think it fails is because sometimes we try to treat TDD as law.

Fallacy of a strict Red-Green-Refactor Loop

In TDD, there’s a concept of a Red-Green-Refactor loop. It goes like this.

Red: Write a failing test

Green: Write the code to make the test pass

Refactor: Refactor the code when needed in order to improve the design.

Don't treat this as a dogma. You don't have to execute TDD in this order to feel like you're doing it properly.

That’s not important. You don’t have to stick to the loop by the letter.

What’s important is that you write the tests while you code (or before you code) in order to reap the benefits of TDD.

The primary benefit of doing this is that you know right away if your code is testable or not. And if it’s not, you can take action right then and there before you pour some concrete that is going to be hard for yourself and anyone else to change in the future.

Knowing how to write testable code can be taught. That’s one of the benefits of the SOLID principles, and it aims to address that.

Conclusion

• developers aren’t being taught the essential software design skills
• lots of companies are practicing agile
• practicing agile means constantly changing and refactoring code
• to refactor code, we need tests
• to write tests, we need to know how to write testable code

Do you see what I see? The first step to addressing this problem in our industry starts with popularizing good software design skills with JavaScript.

In order to go fast, we need to go well.