Most people reading this have flown on planes and used Google to search for something, but would you fly with your family on a plane that was built using the same engineering process as was used to make the first version of the Google Search engine? If you’re smart, you’ll say no, and if you’re not smart, you’re proving Darwin was right! Many executives who commission software development projects are under the illusion that software development is the same as software engineering, but this couldn’t be further from the truth, and this mistaken impression is hurting both their teams and their bottom line. So, what is the difference between software development and software engineering, and why does it matter?
Larry Page and Sergei Brin created the first version of their “PageRank” search engine in a garage in the late 1990s. There was obviously no rigour or procedure employed, and they wrote the software pretty much as they saw fit. It was only much later on when Google became a large company with many software developers that they began following software engineering practices. Today, Google is seen as one of the leading companies for developing new coding standards, with many smaller companies using the Google coding standards to control how their own software developers write code.
On the other side of the coin, you have companies like Airbus that employ large numbers of engineers who may at first sight appear to be doing very similar work to a Google software engineer—they sit at their computers all day, working on complex mathematical and engineering problems. But there’s a huge difference in how an engineer from Airbus does their work versus how a typical software developer does theirs. The reason for that difference is that a company like Airbus is tightly regulated by large, well-funded government bodies in several nations, so they need to follow thousands of rules and regulations, and their products are rigorously tested to make sure they are fit for purpose and safe. This is the opposite of how most software development teams work—at best, a small team of QA testers will check that software is developed correctly and free of bugs. There are no overarching rules and no regulatory bodies for software specifically (although the EU is starting to change that with some of their laws like the GDPR). Software development in most companies is much more like the Wild West than the structured, carefully managed, and rigorously controlled engineering process that you would see at a company like Airbus.
Of course, there’s a good reason why this is the case—most software companies are not building machines that carry millions of people around the world 10 kilometres above the ground at just below the speed of sound! The risk of a software product failure causing harm is hugely lower, and thus many software companies employ no Quality Assurance at all. This is a huge mistake, and it’s one of the reasons why software is so often late, over budget, and full of bugs. It’s also why software is so often seen as a cost centre rather than a profit centre—because it’s so often done badly.
We’ve also seen recently what can happen when companies cut their engineering and quality budgets—on many online flight booking websites you now have the option to exclude flights on Boeing 737 MAX 9 planes, and Boeing’s share price has taken a massive hit because of a string of recent severe safety failures.
At 3 Dot Digital, we have created many different kinds of software over the years for our clients, and we have seen the difference between software development and software engineering first-hand. We have seen that when software is engineered rather than developed, it is more likely to be delivered on time, on budget, and free of bugs. This is why we have created a set of policies, checklists, style guides, and procedures that we follow when we develop software, and we have found that this has greatly improved the quality of our work. We have also found that our clients are much happier with the software that we deliver and that they are more likely to come back to us for more work.
The difference between software development and software engineering is that software engineering is a more rigorous, well-defined, and structured process that is used for building large, complex systems that are used in the real world. Some of the world’s most reliable and widely-used software is written by teams that work more like engineers than developers. The key is to understand the difference and to know when to use which approach, and how it will benefit your business.
So what are some key differences between software development and software engineering? Here are a few:
1. Structure and Rigour:
Software development is often done in a more ad-hoc, unstructured way, whereas software engineering is a more rigorous, structured process. How is this process managed? Generally, it is done by codifying the process into a set of rules and procedures that are followed by the software development team. At 3 Dot Digital, we use checklists to maintain accountability and get real-time feedback for our processes because merely documenting something seldom makes it a reality.
2. Tools and Standards:
Software engineers apply more rigour to their work than software developers. This means that they are more likely to use tools like version control, automated testing, and continuous integration to ensure that their code is of high quality. They are also more likely to use tools like UML to model their software before they write it and to use tools like JIRA to manage their work.
3. Quality Assurance:
When it comes to Quality Assurance, companies that ENGINEER software are more likely to have a dedicated team of QA testers who will test their software to make sure it is free of bugs. This is a huge advantage when it comes to delivering high-quality software, and it’s something that software developers often don’t do. In addition, leading software engineering firms like Amazon and Microsoft will often create automated QA testing systems that can simulate user interactions with their software, and these systems will run continuously to make sure that the software is always free of bugs. The beauty of testing software using automated systems is that it can be done continuously, and it also provides a reliable baseline for the software’s quality. This is a huge advantage when it comes to delivering high-quality software, and it’s something that software developers often don’t do or can’t be bothered with because it doesn’t “seem like software development” to them. Of course, the worst-case scenario and the one to be avoided at all costs is when a software development team has no QA at all, and the software is tested by the end users. This is a recipe for disaster and will inevitably result in unhappy end-users!
So now that we’ve learned the difference between software developers and software engineers, how do we apply what we’ve learned?
What’s needed is to change your approach from developing software to engineering it. How do you go about doing this?
1. Codify Procedures:
To start with, all of the procedures your team follows should be codified into a set of rules and procedures that are followed by the software development team. This is a good idea because many teams have “hidden” procedures that are not written down, and this can lead to confusion and mistakes. This step alone can greatly assist particularly junior developers who are new to the team, and it can also help to ensure that the team is following best practices. By closely examining the procedures that your team follows, you can also identify areas where the team is not following best practices and work to improve those areas. It’s surprising how awful some teams’ procedures are and how much they can be improved with just a little bit of effort.
2. Shared Access and Regular Reviews:
These procedures should then be placed in a shared location where everyone can access them, and they should be reviewed regularly to make sure that they are up to date. This is a good idea because many teams have procedures that are out of date, and this can lead to confusion and mistakes. There are great software packages available to make this easier like Atlassian’s Confluence, which is a wiki that is designed for teams to share information.
3. Ensuring Accountability:
But documenting a procedure is a great way to make sure that your team will never follow it—how do you ensure accountability and actually get your software engineers to USE a procedure? You might think of putting it into Jira or other project management software, but there is a better alternative—use a checklist system like Didit, which is an app for Confluence. The beauty of using checklists is that they are very easy for your software engineers to work with, make it almost impossible to forget what they have to do, and provide rich feedback and emailed reports on completion. This is a simple but powerful tool that a lot of software teams forget is available.
4. Planning and Standards:
The next step is to plan how you will engineer your software rather than just develop it. Engineers generally follow strict standards and regulations—for example, how strong a steel beam needs to be to carry a certain load or checking whether a structure can handle a projected quantity of wind shear. The software engineering equivalent of this is to use Unit Testing and Automated Testing. Unit tests allow developers to test whether a piece of software will break any other systems before it is even deployed, and automated tests allow developers to test whether a piece of software will break any other systems after it is deployed, but before customers receive the software. This is a huge advantage when it comes to delivering high-quality software, and it’s something that software developers often don’t do.
5. Using Coding Standards:
Using well-known coding standards such as the Google standards is very helpful because these standards have been developed over many years by some of the best software engineers in the world, and they are designed to make software more reliable and easier to maintain. This is a huge advantage when it comes to delivering high-quality software, and it’s something that software developers often don’t do. That doesn’t mean that a slavish adherence to these standards is necessary—in fact, it’s often better to use an approach where exceptions can be made to the standards, but only if they are documented and justified. This is a good idea because it allows developers to use their own judgement, but it also ensures that the codebase remains consistent and maintainable, and the very process of justifying the exceptions in a social setting can often be a positive learning experience, particularly for junior developers. A good place for this to happen is inside Pull Requests, where the code is reviewed by other developers before it is merged into the main production codebase. By using these engineering standards, software developers can bring their processes a little bit closer to the rigour that other engineers use.
Software developers as a group have a tendency to be resistant to change, and they will often resist the introduction of new standards and procedures with particular ferocity. Why is that? It’s because they are often under pressure to deliver software quickly, and they will often see the introduction of new standards and procedures as a waste of time. But following these procedures, software developers can bring their processes a little bit closer to the rigour that other engineers use, and they can also ensure that their software is of high quality.
This is the biggest challenge of all—to convince your team that the introduction of new standards and procedures is a good idea. The best way to overcome this challenge is to show your team that the introduction of new standards and procedures will make their lives easier and that it will also make their software more reliable and easier to maintain. A good way of explaining this to your team is by helping them to see that many of those late nights and weekends spent at the office were actually caused by not following engineering principles that are viewed as standard practice in the rest of the engineering world.
Creating software is a creative process, and it’s often difficult to convince people that it can be engineered. But the truth is that software engineering is a creative process too, and it’s often more creative than software development. But it’s important to make sure that you bring your software development team along for the ride, for example by involving them in the process of creating the new standards and procedures, and by making sure that they understand the benefits of following them. This is a good idea because it will help to ensure that the team is on board with the changes, and it will also help to ensure that the changes are successful because they will feel ownership of the changes.
While writing software “free-form” and not having to focus on standards and procedures is really fun and enjoyable at first, eventually all software developers will run into the same problem—the software becomes too complex to maintain without rigorous standards and procedures in place. By putting these systems into place at the beginning of a project, it makes the project easier to maintain and less prone to bugs. This is a huge advantage when it comes to delivering high-quality software, and it also helps new team members that join later to understand what is expected of them as they begin contributing to the project.
In conclusion, the difference between software developers and software engineers is that software engineers apply more rigour to their work than software developers and can thus expect a higher quality of software as a result, as well as a less stressful and shorter development process.
At 3 Dot Digital, we don’t just engineer software for our clients, we also have services where we can help existing teams with our “Virtual CTO” service. We help teams implement these procedures and standards, and we can also help review the work of existing teams to ensure that they are following best practices. If you would like to know more about this service, please get in touch with us on our website or subscribe to see more content like this. Thanks for reading!
