Top 5 Most Common Web-Development Issues and Their Solution
In our Development & Code Reviews we see development teams facing the same common web-development issues, we’ll share them and different ways to improve your web-development
From all the reviews we have done, these are the top 5 most common web-development issues:
- Web-Applications use Outdated Open-Source Components
- Automated Testing is Not Used, or Used Badly
- Deadlines and Budgets are Exceeded Very Often
- Documentation and Installation Automation is Severely Lacking
- Developers are Not Continuously Learning and Improving Their Skills
In this article we go in-depth in each of these issues on why it is important and how to fix it.
Web-development issue #1: Web-Applications use Outdated Open-Source Components
- Study shows 91% of commercial applications contain outdated or abandoned open source components.
- 99% of code bases contain at least some open source.
- 75% of code bases contain vulnerable (outdated) open source components.
- Over 95% of companies postpone major updates (ex. to open-source frameworks) often or indefinitely.
Open-source is great. We all use it, even though most of us don’t contribute to it. We do contribute, and we know the major work involved in making open-source easy to use, well documented, keeping it up-to-date and support the (combinations of) old versions.
Unfortunately many developers and companies are afraid to update. Whether it’s a
composer update in PHP or
ng update in angular, frameworks and tools make it easier and easier for us to stay up to date, but why then are we afraid to update, especially major versions?
For any developer who hasn’t started yesterday, we know that historically updating has been a pain in the butt and although some frameworks are doing great work at making transitions easier and easier with backwards-compatibility promises, updating still often leads to broken code.
The issue is often that we only update when we need to. Maybe we want to use some new feature. Or maybe some other component has some requirement for a newer version. Whatever the reason it interrupts our programming and leads to an update that perhaps leads to another update and soon starts breaking your application. So what do we do? Revert the change and find another solution.
Obviously this leads to only further outdatedness, making future updates even more complex, eventually leading to questions of perhaps simply starting anew with a newer version or entirely new framework. In my experience this always leads to more work and new unintended bugs.
So, not consistently keeping up-to-date will soon make updating a major effort.. while not updating has major security risks and keeps developers back from better and faster new solutions.
Do you even know if your application contains parts that are considered outdated? All major frameworks nowadays keep a record of what versions are still being maintained, either actively or only for security fixes. Unfortunately many developers never check this. In our code reviews we’ve seen many applications, some not even 2 years old, already using components considered so far outdated that they posed security risks.
You get it. You should update. Nobody wants security vulnerabilities and you would love to use the new features that new updates have to offer, but how to get through this fear of updating?
Here’s some solutions:
- Get a buy-in from management with some of the shocking statistics that time should be reserved for deferred maintenance, so your team can do a couple of updates at the same time and get back on track. This will probably cost a few days, but the investment is well worth it in added security, performance and features.
- Schedule updates in advance and put someone in charge of them. Updating often and taking care of deprecations early will lead to smoother updates and less problems. We update all open-source components to the newest version that is at least a month stable. You can make your own rules, but more important is to assign someone that makes sure those rules are followed.
- Use automated testing (see below) to mitigate the risks of updates having unintended consequences. A much-heard objection is that updates can lead to bugs. Not updating has the same risk, so in our opinion it’s a bad argument, but still true. Proper automated tests can catch all of the issues an update could bring and help you do updates more smoothly.
- Read UPGRADE documentation! I can’t believe how often developers re-actively update (because of some new feature needing the update) and then in their haste don’t read the docs for the upgrade, leading to easily preventable bugs. Most open-source has pretty good documentation on how to upgrade and what has changed, use that!
Interested if your application is outdated and has security vulnerabilities? We’ll happily do a development & code review for you to find out!
Web-development issue #2: Automated Testing is Not Used, or Used Badly
- 72% of mid-size to large companies are using automated testing.
- Only about 5% of those are achieving anything close to full test coverage.
- Of those using automated testing, about 78% relies heavily on functional and e2e tests.
- 28% of larger companies do not use automated testing.. we don’t know how many smaller companies are not using automated testing, but from our experience we expect those numbers to be significantly higher.
- According to a 2016 study, the use of automated tests has increased by 85% in a two-year period, gaining popularity faster than ever before.
- At the same time, many companies have trouble implementing even basic test automation. As many as 41% of IT teams have confessed to lacking proper auto testing methods.
Automated testing is rapidly gaining popularity. This is great! We love automated testing and everything it can do for your business. We see and more companies dipping their feet and start to implement, but oftentimes they make all the beginner mistakes (as we did, back in 2010). This is a tremendous waste of resources and bad automated testing can lead to sub-par results, not really giving you the benefits and adding more issues and work. That’s not what we want at all!
Automated tests should be saving you lots of money:
- Less or no manual testing needed. With 100% coverage you don’t need manual testing for bugs – only “testing” if features are built to specifications. Even with less test coverage, you can greatly reduce manual testing time, as common repetitive tests can be automated. Less or no manual testing is money saved for something else.
- Automated tests speed up development. Some developers will argue it costs more time to write tests and therefore development will slow down. We find the opposite is true. As long as you can easily and quickly execute all tests locally, a developer will save a lot of time testing his own code manually.
- Improved code quality through immediate refacturing. On top of faster development, we also find that creating an automated test directly and using TDD (test-driven development) practices, you actually think about the code you build twice (instead of only the one time without the test). I’ve often refactured code when creating the test, for example because it didn’t make sense from the test perspective. This may sound as extra “stupid” work, but in my opinion the code only improved and became more readable and better re-usable. Doing this directly can also prevent bigger refacturing down the line.
- Used as a fail-safe. Automated tests can be run automatically and block updates when tests fail. Manual testers can more easily forget to test. They are less reliable than automated tests when it comes to acting as a fail-safe. And of course we all want our code to be bug-free when going to production.
We love automated testing and telling you all the reasons why we believe it’s vital is beyond the scope of this article. Unfortunately many companies remain unconvinced or the developers that implement it don’t have the right experience and have implemented it badly. About 80% of implementations rely too heavily on functional or e2e tests, leading to slow tests. This slows down development, leads to slow pipelines and skipping, leading to the very bugs you wanted to prevent.
Automated tests are an important part of our Bug-Prevention Pipeline™. Download our free e-book and learn how to optimize your pipeline and automated tests.
Web-development issue #3: Deadlines and Budgets are Exceeded Very Often
- In a 2013 survey of 4,048 individuals in software development communities by VersionOne, more than 84% of respondents said their organizations were practicing agile development in 2012
- In a 2008 independent study of over 7500 traditional and agile projects, QSM Associates concluded that, as compared with industry averages, the development teams utilizing agile practices were on average:
- Thirty-seven percent faster delivering their software to market
- Sixteen percent more productive
- Able to maintain normal defect counts despite significant schedule compression
- Agile adoption is now the norm and has replaced Waterfall
As developers we have mostly shifted from Waterfall approaches to Agile development practices. This is already a big step forward, but we’ve also seen many issues with companies implementing Agile, SCRUM, LEAN or Kanban practices.
We believe – and show in practice – that implementing the right system and getting developers to actually follow through with the practices, will lead to the ability to set proper expectations and keep or exceed them, resulting not simply in deadlines met on-budget and on-time, but the actual higher-level results understood, tested and achieved.
In our experience the biggest bottleneck is generally a good (product) owner that leads the team actively and in harmonic teamwork to the desired result, making the team an active participant not only in the tasks, but in the achieving of a business goal.
Our own developers tell us again and again how happy they are to be actually involved in the results of the projects they are working on. We love transparency and when a bigger team, which includes the developers, can together look at important business KPI’s, this will lead to new insights and improvement the product owner has never thought about. It should be the numbers that decide the next steps. Not some vague ideas from the owner.
How does this tie into deadlines and budgets? We believe the whole concept of deadlines and budgets is a wrong management approach. What would you rather have: a developer invested in being done in the least amount of time (no matter the postponed cost) or a developer actively invested in business results, such as rejecting tasks that serve no purpose, investing in long-term health and maintainability and finding out from statistics which features are most urgent to build or improve?
When used properly SCRUM or LEAN methodologies do not have deadlines. They have sprints that continuously improve the products and deliver real results. When you are still chasing deadlines and budgets, you are not using Agile practices as they were intended.
Interested to know how Agile your development team is and learn more about how your team can be more efficient and deliver more real results? Start with a development review for just € 297.
Web-development issue #4: Documentation and Installation Automation is Severely Lacking
- Less than 25% of respondents in 2017 Holdraf & Varoquaux study spend as much or more time writing documentation than they think they should.
- From a 2005 DBLP study the most important (according to 92.5% of survey respondents) documentation is in the source code itself.
From over 20 years of experience I can confidently say that documentation that lives outside of the source code is only rarely checked. The most important documentation outside the source code is in our opinion documentation on the coding guidelines and best practices. Although in our opinion this should always be using the industry standards as a starting point, it is very useful to go more in depth, especially for new developers joining the team, as to how the team solves common issues. This leads to a more uniform code base, which is easier to maintain and add to.
Inside the code we expect at least the following documentation:
- Installation instructions: It’s amazing how often this is either lacking or not up-to-date. Ideally much of the installation should be automated, but even if it seems quite basic, it’s very useful to have proper installation instructions that will actually lead to a working application. Without these instructions we have seen new developers easily take 1-2 days to get up and running, where with these simple instruction this can be done in under an hour. If a new developer runs into trouble, it should be a priority to directly update the documentation and let them use the new documentation to verify it.
- Links to other important documents: Adding a few links, such as to the teams’ coding guidelines or framework documentation can help newcomers tremendously to get up to speed quick.
- Explanation of manual scripts or commands: Most applications have some scripts or manual commands that are used in specific situations. It’s best to avoid this as much as possible and automate where possible, but it’s almost unavoidable to have some of these. Make sure their uses are well documented to avoid a single developer being a bottleneck or single point of failure.
- Deployment instructions: Unfortunately for most applications deployment is at least partly a manual process. Too often this is in the hands of one or a few senior developers that simply tell each other how it works. But what if those few are unavailable? There’s also many other arguments for everyone being able to deploy the application. If this is too error-prone then you should consider at least partly automating the process and making it less error-prone. Quick and simple deployment prevents a lot of issues and can help solve issues quickly that do pop up.
- Testing instructions: Either how to run automated tests or what should be tested manually before each deployment. This is often overlooked, but very important to prevent errors that could have easily been found with the right system.
- Instructions to access testing and production environments: Whether it’s a malfunctioning server or overflowing database, it’s always important that developer can quickly solve issues in the production environment. Of course security can be an issue here, but as much of possible, with the proper security layers, we believe that all active developers should be able to access all environments. This is made easy by proper instructions on how to access each system. This is especially important when using complex DevOps systems such as Amazon AWS, which can be tricky to work with for the average developer. In those cases we also strongly advice some knowledge sharing sessions with the developers about these systems.
- Component and code documentation: In general we believe code should be self-explanatory and programmed in such a way that future developers can easily read the code. We train our developers on this, because it’s easy to make something too complex and hurt the readability. Of course documentation should naturally be part of the code itself in the form of comments or docblocks. In some cases solutions may require a separate explanation in the documentation to explain how a certain component is meant to function and why certain choices were made.
As you can see there’s lots to think about in terms of documentation. It’s easily overlooked and since the developers should take care of this themselves, it’s similar to things like automated testing: if the developers don’t see the value and don’t take responsibility to add documentation or automated tests, it simply won’t happen.
Therefore we help teams see the value of both and implement simple systems to help the team keep documentation up to date. Interested to learn more? Let us do a development pipeline review and/or code review or hire us directly to help you get your development team to the next level.
Web-development issue #5: Developers are Not Continuously Learning and Improving Their Skills
- On average in 2018 employees got just 34 learning and development hours per year.
- Code/PR reviews are the #1 source of learning for most developers, because most companies invest little to nothing in training sessions or other forms of learning
- 85% of developers we ask cannot tell you the latest features of the main programming language or framework they are using.
Developers are mostly left to fly solo. Maybe it’s because management doesn’t understand how programming works. Maybe it’s the time and money investment. This leads to huge difference in the skill-level of developers and also to a very mixed quality of work in a larger application. Even though PR (peer) reviews are getting more common, they are often not used to enforce standards and teach.
PR reviews are by far the most important tool most developers use to learn from each other, but unfortunately we see that this great tool is very under-utilized. The most common reasons are:
- (Senior) developers are too busy to give in-depth comments.
- There are no clear and common standards to help each other with.
- Developers are afraid to give negative or critical comments to colleagues, fearing to hurt their feelings.
- PR reviews are abandoned or only done sporadically because it generally takes too long to wait for a review.
- Reviews are too much about small details or seeing bugs and not enough about teaching.
PR reviews can be a powerful tool when used correctly, but in our opinion they are best used in combination with both proper documentation (of development standards), automation where possible and knowledge sessions to share awareness and discuss new updates, new practices and other new approaches.
At Solid Web Code we have weekly group coaching sessions, strong coding guidelines and half-yearly study events, on top of PR reviews and retrospectives to continuously improve our knowledge and share it around.
Some people just naturally like more to stay up-to-date on the newest technologies. Others are great teachers. Use the skills your teammates have and assign responsibilities, while getting the whole team on board with the importance of learning and growing. Avoid developers to get stuck in a routine and stop learning. Especially for programmers this is very bad as technology is advancing so rapidly. We only work with developers that have a strong growth mindset and use it as a main criteria for hiring, perhaps you should do the same.
We see so much waste of time and energy in web-development and as a team of growth-minded developers, we love to help you raise your standards and get back on track of fast and efficient development.
Are you plagued by web-development issues?
Are you going to stay too busy to fix it?
You know that laying a solid foundation for your developers will save you money and time in the future.
You know you should invest in prevention, instead of constantly fighting fires.
Let us help you.
For just € 297 we’ll do a development pipeline review for you, so you can get your team back on track.
Or for € 997 we’ll do a development pipeline & code review and help you decide the quality and next steps for your product.
Or maybe you are already overwhelmed and simply want our experts to work with you, creating new features and at the same time slowly raising your standards and improving the foundation of your development team.
This is not a quick-win.
But you know it’s necessary.
Drop us a chat (look to the bottom-right) or contact us if you have more questions.