When working on a project, the temptation is strong to make everything perfect before showing it to the world, or even just to your co-workers. You know each and every line of code you wrote, but you have a long list of bugs to fix and don’t want to expose your work until you’re completed everything that was on your TODO list. Shipping is scary, so you’re holding back with the excuse that you need to fix another bug before finishing.
If you want to make software people use and enjoy, and not just write code for the sake of it, you must get over yourself and ship! I’ve seen people holding onto code for ages, polishing it to perfection, only to leave the job before anyone had time to see the results and give valuable feedback.
The same goes if you wish to get feedback on code you’re doing as a side project. If you’re not shipping, nobody will be able to comment on your code and you won’t know if you’re going in the right direction. Agile methodologies have the right ideas about this. Getting used to shipping small changes will help you fight the urge to keep your code to yourself and having to push huge modifications at once because you’ve been playing it safe.
Also, we tend to underestimate the value of our software. A tool that will help improve business processes will be used and appreciated if it does the job, warts and all. When an application makes people’s work easier, they won’t mind putting up with some bugs for a while until you have time to fix them.
You want to validate with your users that you built the right thing as soon as possible, and there are many flaws you’ll see only when people are using your product. What if the incomplete feature you were planning to spend a few weeks on is not really needed? Better to know right away instead of sinking a lot of time into it.
The caveat is that you must allow time to go back and fix those problems when they’re found. On the other hand, you don’t want to fall victim to “ship the prototype” syndrome: if every time you show a quick and dirty prototype it ends up in production, you must make sure that what you show is solid and well-structured even if it’s incomplete. Shipping something is an important milestone, but it’s not the end of the project.
Creating a custom web application is a big investment for a small business. Getting it done requires a lot of work, starting with discussions about needs and specifications and followed by coding, demos and adjustments. It’s tempting to say that everything is be over and done after all this and that nobody should need to touch that piece of software again. Consulting engagement are also often structured this way and not as a retainer, but that’s a flawed approach: software is a living thing that needs to be adapted again and again to stay relevant.
Here are some of the reasons why you need ongoing investments in your software to get the best out of it and keep your clients happy for many years:
New features are needed
You may think that you’ll never need a new feature, but something always comes up sooner or later:
A new social network or other application comes out and you must absolutely support it for marketing purpose or for your users.
New law and regulation comes out, forcing you to revise how taxes and rates and calculated.
An existing tool you were using closes down, for example your payment processor, forcing you to move to another one.
You’re doing a new promotion, special offer or program and need to add something to support it.
Those reasons may not be related directly to the core functionally of your software, but in most cases you won’t have any choice if you want the business to keep working it.
Technology keeps moving
Technology keeps progressing at a neck-breaking speed. Less than 5 years ago, few people had a smartphone: the first iPhone with was launched in 2007, and it had a tiny screen by today’s standards. Tablets are even newer: the first iPad was launched in 2010, and the first Android version made for tablets in 2011. But right now, you cannot ignore mobile if you’re building web applications: users will access it using their mobile devices whether you like it or not.
What’s going to be the next big thing in the next five years? Watches? Virtual reality? It’s pretty hard to plan for things that don’t exist yet, but when they happen your software may need to be adapted to it as users ask for it.
Servers are updated
All web applications must runs on web servers. Those servers have their own software, and those are also updated for security reasons and to add new features. Over time, this may also require modifying your web application as older versions of the software they are running on are no longer supported. Staying on the old software is not a very good option: over time, it stops being updated so it will be more and more insecure as time goes it. It’s not worth betting the privacy of your business and your customers on old technology.
New browser versions comes out
Before, web browsers were updated slowly and a new version was a big thing. Nowadays, browsers are automatically updated with the newest features every day. It’s rare, but a small update can break your site even if it was done well if a browser changes a small detail in a feature or introduces a bug. The web standards also evolve all the time, and browsers adapt to those changes: new features being added all the time and old ones are no longer supported. Over time, those needs to be adapted so the application keeps working correctly on all browsers and devices.
In conclusion…
For all those reasons, any application needs to be cared for during its lifetime to make sure it stays healthy. If you’re not ready to make that kind of investment, an off-the-shelf application that requires less investment but that is harder to customize may be the better way to go. It will also need to be maintained and may not have 100% of what you need, but it is less work because others will be in charge of evolving the core of the application. But if you want to have a custom application and take care of it, you need to be ready to do what’s needed.
I’m not the most minimalist person in real life: I always have a ton of things going on, be it gardening, cooking, crafting or coding projects. This is a pretty common plight for a programmer since we like to tinker. But when I code something for production and not as a toy project, I believe that minimalist is something important to keep in mind. This way, my code is simpler and easier to maintain for me and for other people.
There are many aspects to minimalist in a software project, from your technology choices from the start to good coding practices when the project is ongoing.
Keeping you code simple
The number one priority is readability and easy of maintenance, by you and by others. Trying to reduce the length of variables names or function names at all costs gets in the way of being understood. You want to keep a reasonable length so the names are clear while still being able to fit a line of code on the screen. Another good thing is to use a common coding standard for all the code on a project: there is no one true coding standard, but it’s easier to understand code without distractions when it all looks similar. In doubt, you can just use the same standard as the library or framework you are using.
Also, you want to eliminate pointless complexities in your code. First, all the code in your codebase should be actually used. Don’t code things just in case they may be needed. It just adds more moving parts that needs to be maintained, and when the case you coded it for finally happens, you’ll most likely find out that what you need is a bit different than what you implemented anyway. Following the same ideas, parts that are no longer needed should be removed, not just commented or left lying around. You can always retrieve the code you removed using source control if you ever need it again.
Finally, keep the things you are doing simple, for example, don’t use CSS selectors from hell if you could simply add a meaningful class to your markup instead. Also, useless conditions should be eliminated: if doing a piece of logic every since time has not negative consequences and has a negligible performance cost, you can do it all the time. It may even be faster to just run the code instead of checking a condition! Also, you can use returns to leave methods as early as possible to reduce the levels of indentation and make code easier to read.
Using libraries
If your goal is maintainability, you can’t always go with the shiny new toy: something new is always a risk, and you don’t want to spend a lot of time with it if it’s going to be dropped in a few months. So, when I create a new project, I aim to start with as little components and tools I can get away with. The simplest code that is closest to the HTML/CSS/JavaScript standards are always the best for long-term maintainability.
For example, for a ASP.NET MVC web application, even the default template is pretty bloated: the ASP.NET MVC framework itself (and the dependencies like the Entity Framework), jQuery and a good control library like jQuery UI is more than enough. Any additional library that you add have a cost: they will need to be maintained and updated, and you have to keep yourself up to date with all the new upgrades. If you are not using the library at the moment or only a tiny part, it’s a lot of noise to sort through while you could be doing something that moves the project forward.
Don’t get me wrong, I’m not anti-library: I don’t believe in reinventing the wheel, and if a part of my application has special requirements not covered by the .NET framework, I’ll gladly use a library that implements it. For me, a good library to use is one that does the job it needs to and not a few dozen other things, has good documentation and is regularly upgraded and maintained. It also should not take over my architecture by forcing me to use complicated patterns and by pulling along any other dependencies.
Separating concerns
I’m not a testing wizard, but there are many things you can do to help yourself start on the right foot even before you start writing that first unit test. First, you should have a simple but clean architecture, separating the business logic in the model, the controllers getting the data and the views handling the display logic. The truth about the business logic should be kept in one place in your architecture so it is easier to modify it. For performance and usability, you can add a few validations to the client-side JavaScript, but the server-side code saving the data should always has the last word. A validation that’s on the client can always be bypassed anyway, so you should never trust something sent to the server by the browser.
Also, on a lower level, you should make it clear what are the responsibilities of each class and method is doing and document each of them properly, including all the edge cases. I don’t believe in zero comments: the documentation is there to explain why you are doing something and how to use that method, not just to repeat details about the inner working of the method. A method should do only one thing: if it gets too big, it’s going to be hard to know what are all the possible code paths. Nice and small methods or views with clear responsibilities are easier to reuse in your code, and don’t need as many new tests since it’s known code.