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.
But also, in the most lovable way possible...
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.
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.
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.
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
So it's apparent that knowing how to write maintainable and flexible code is incredibly important.
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.
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.
- 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
In order to go fast, we need to go well.
Thanks for reading! Share this article if you found it useful.
Stay in touch!
View more in Web Development
You may also enjoy...
A few more related articles
Learn how to use DDD and object-oriented programming concepts to model complex Node.js backends.
In software, change is inevitable. The more complex the software, the more it should be enabled to be changed. The SOLID principles are a set of principles all developers should know about in order to design robust, maintainable, and flexible software.
Want to be notified when new content comes out?
Join 2000+ other developers learning about Domain-Driven Design and Enterprise Node.js.
I won't spam ya. 🖖 Unsubscribe anytime.