Building Applications that Last

Some have been transient, only serving a specific purpose for a window of time, while others have persisted for years on end.

We've learned a number of key lessons while building and maintaining these long-term applications and we wanted to share them with you.

It's not about the tech

Tools like Laravel and Vue have exploded in popularity in recent years and for good reason. They offer leaps and bounds in terms of productivity and I would not want to program without them. However, they do come with a level of risk. While high-level programming practices remain steadfast, low-level implementation is subject to frequent changes. It's important to choose solid, time-tested frameworks/languages that will still resemble themselves 2-5 years from now. Avoid the temptation to pick the latest fanciness and opt for the tech that has established patterns of stability.

Choose straightforward over clever

Good programmers are always learning. They should be keeping abreast of industry trends and dabbling in techniques that look promising. It's important they have a measure of cynicism though and don't try to implement every new pattern they come across. Ask yourself "Will I, or the next programmer to pick up the project, easily understand this approach?" Make sure your project is written in a manner that the intentions are clearly communicated in the code. If you can't read it and understand what's going on at a cursory glance, it might be too clever. This also goes for adding new patterns to an existing project. Unless there is a good reason to deviate, it’s best to follow the established patterns.

Pay attention to your data structure

One of our applications has generated a huge number of database records due to the way we structured our data during the initial design. We've had to make accommodations to store such large volumes and would probably do it differently next time. Perhaps your application will not experience large scale, and you should certainly not pre-optimize, but consider what would happen to your storage mechanisms if your user base was 10, 100, 1000x what you anticipate it to be. Are there accommodations you can make during design that won't be too difficult to add now?

Don't offload critical aspects to third parties

Because your application will have features that are central to its operation, be very cautious in offloading that functionality to a third-party service. Sure, another company may offer a feature XYZ and save you time during initial development, but you have no guarantees the service won't be deprecated or modified in such a way it won't meet your needs in the future. Own the important things and supporting your application will be easier down the road.

Bind to as few dependencies as possible

Nearly all software is built by grouping a bunch of packages together; it's highly unlikely that you would write your program straight from the root code. Because your program will depend on a bunch of code written by a variety of people it's best to try to keep that number as low as possible. If the framework offers 90% of the thing you are trying to do, write the last 10% yourself instead of using someone else's package. This will allow you to direct your application without having to worry if the other developer will change their package.

Keep upgrading

As the base framework continues to offer updates, do your best to apply them in a timely manner. This is a much more dependable way than to wait years on end before doing a mass upgrade. Incremental updates applied over time will result in smaller bugs, fewer quirks, and a more secure application.

Maintain the test suite

I'm going to assume your application has a robust test suite and that it is successfully run as changes are made to the app. Without this assurance, you are flying blind and risking a great deal of stability. Not only do the tests provide confidence that new additions aren't breaking existing features, they are a great source of documentation for new developers coming on to the project. So keep dust from collecting on the tests, add regression tests as you fix bugs, and keep a high level of coverage as new features are added.

Add monitoring

There are myriad services that offer error logging and monitor performance. Set them up to notify you when things go awry and as you address the issues you will see the application stabilize.

In conclusion

While there are other lessons we've learned, these eight have risen to the surface as ones to pay special attention to when building and maintaining applications for the long run. Follow these lessons and your application will be more stable (plus you will sleep better at night)!