How NOT to develop software in 2023
In the fast-paced world of software development, staying on top of the latest trends and technologies is critical. We've had our fair share of learning to do over the years!
There are plenty of guides on how to build modern software, in hundreds of different variations, however sometimes it's helpful to flip this on its head and identify what not to do when building an app.
In this blog post, we'll explore some common mistakes that we have seen on modern software development projects and provide examples of better alternatives.
Not using a framework
One common mistake that some software teams make is trying to build an app from scratch, without using a framework.
While this may seem like a good idea in theory, it can lead to a lot of unnecessary work and bugs. Frameworks are designed to make developers' lives easier by providing a set of tools and conventions for building web applications.
For example, if you're building a Node app, you might consider using a framework like Express or Fastify. They provide a set of middleware functions that can be used to handle requests and responses, as well as a routing system for handling URLs. This can save a lot of time and effort compared to building these features from scratch. This might feel like a no brainer, but we have seen this stuff rolled by hand countless times.
Using technology with low community adoption
Another mistake that developers make is using technology with little or no community support or adoption.
This can lead to a lot of headaches down the line, as it can be difficult to find documentation or support when you need it.
For example, if you're building a front-end app, you might consider using React rather than a less popular framework. React has a large and active community, which means that it's easy to find help when you need it. It also means that there are a lot of third-party libraries and plugins available, which can save a lot of development time. (See the point above!)
Ignoring business requirements
One of the biggest mistakes that developers can make is not listening to the business.
While it's important to use your expertise to guide the project, ultimately the client knows their business best. Ignoring stakeholder needs and requirements can lead to a product that doesn't meet expectations. You should work with the business, offering your knowledge and opinions, to reach a solution that is right for the customer.
Hypothetical scenario, you're building a mobile app for a client, you might think that a certain feature is unnecessary or too complicated. However, if the client is insistent on having that feature, it's important to listen to their reasoning and try to find a way to implement it.
Hand-rolling utilities that could be modules
This is a biggie, but it also involves a fair amount of nuance - especially in the Javascript world where anyone can publish their own modules to places like npmjs.org.
Writing your own complex utilities instead of using readily available open source modules can lead to a lot of wasted time and effort, as well as increased risk of bugs. For example, if you're building a Node JS app, you might need to handle date and time calculations. Instead of writing this code from scratch, you could use a module such as date-fns.
As mentioned before, some nuance should be applied to this practice. There will be times that using a 3rd party module is not an appropriate or safe course of action. Perhaps no one has solved the problem you're trying to solve, or a package is no longer actively maintained. Navigating this decision can be tricky at times, so we created a helpful checklist to help evaluate this:
- [ ] Is the package licensed in a way you can use?
- [ ] Is the package's latest published version free of known security vulnerabilities? (can check with https://snyk.io/vuln/npm:moment)
- [ ] Is the package tested? (there should be at least some unit tests)
- [ ] Is the package lightweight? (you can check this with https://bundlephobia.com, this should be considered alongside the size of the problem being solved)
- [ ] Is the package dependant on no other packages? (0 dependencies = less to worry about)
- [ ] Is the package maintained? (activity in the last year, don't forget to check branches other than master)
- [ ] Is the package popular and widely used? (depended on by lots of other projects, number of stars on GitHub)
- [ ] Is the package well structured and easy to understand? (could you contribute and make changes to it quickly? You may have to!)Once you do decide to adopt something, it's a good pattern to only import it in one place (like an internal `helper` library) and to reference that in every part of the codebase where it's needed. This is in case you decide to replace it in the future, so you only have to change it in one place.
Over-optimising
Another common mistake that developers make is focusing too much on being clever and over-optimising solutions rather than delivering a practical product. Lets face it, we all like to flex our brain muscles every now and then, and while it's important to be thorough and come up with new ideas, it's equally important to focus on what will make the app valuable for users.
Imagine you're building the first release of a new application. You have an app with basic features and acceptable page load times, you are now at a crossroads. You can spend time optimising the requests and making the pages load very quickly or you could add some interesting user-facing features.
At this point, it would be a mistake to spend too much time optimising and caching requests when there is still so much low hanging fruit up for grabs in the form of new features for users. You should always be careful when balancing feature delivery against technical improvements - a lot of the time, users wont notice a few milliseconds shaved off of a page load, but will really appreciate shiny new features that make their life easier. Always think of the user!
Weak leadership and bad communication
One of the biggest challenges in any software project is managing the team and ensuring that everyone is working towards the same goals. A lack of leadership can lead to confusion and delays, as well as a lack of accountability.
It's important to set clear expectations and milestones and do your best to meet them. It's inevitable that at times, these milestones will slip, it is important to communicate this early and openly. Once a slipping milestone has been identified, steps can be taken to course correct the project. We like to employ a very simple but effective tactic at these times - prioritise and execute.
It’s critical for teams to clearly and decisively prioritise and execute when faced with curveballs and slipping deadlines. We'll give some examples below of how to do just that in a situation where a project's delivery date is slipping.
Prioritise
First things first, collate a list of all the current outstanding tasks on the project. Consult the whole team in case there are tasks you might have missed.
Rank the tasks in priority order. Work with project stakeholders to understand what features are critical to the mission's success.
Identify tasks that can be cut from the release. Sometimes, no matter how much time and effort you put into a time critical delivery, it is not possible to meet the deadline with the current workload. As a last resort, you should negotiate the removal of features from the release. The ranked task list should make this easier.
Explain the number one priority to your team in the most simple and straightforward way possible - don’t leave any room for mis-interpretation.
Execute
Figure out the solution to the highest priority task. Bring everyone together to mob on the solution and remove any blockers. Ensure you end up with a list of acceptance criteria for the task so you can measure when the task is complete. Ambiguous requirements lead to scope creep.
Assign a subject matter expert to complete the task. When faced with urgent deliverables, it is best to assign a subject matter expert to the task in order to get it over the line quickly. To help with knowledge transfer, you can always pair them up with another engineer.
Repeat the process. Continue to repeat the prioritisation and execution process until the project is delivered. Have regular progress check ins to ensure you are still on track.
These are just a few things that we have learned to be conscious of when working on large, complex projects.
If you're looking for a team who can avoid these pitfalls, feel free to get in touch with us today via hello@logicful.co.uk.
