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.
I wanted to start the real code for my side project by making a small skeleton of the project in ASP.NET MVC. This skeleton includes a basic form to create an event, which will be the starting point of the application. An event has a name with a start date and an end date that are represented as DateTime, so I figured I’d try my hand at integrating the jQuery UI datepicker to my form. That way, I’ll be able to make sure that jQuery UI is properly included in the application.
First, I included a bundle for the jQuery UI library along with jQuery on the page where I wanted the date picker to be.
After this, I created a input box using the TextBoxFor Razor helper which will be used to initialize the datepicker in JavaScript. I used the short date string so I would only get the date and not the time, and set the control as being read only so the user would be forced to pick the date from the picker. That way, I won’t have to handle the various date formats that could be entered.
This already looked good when the page was first loaded, but there was a bug when a date was selected in the picker: the format of the date was not the same. Here is how it looked like with the original start date and the end date that was modified by the date picker:
It works for saving the date, but it doesn’t look very good so this has to be fixed. But why is the format wrong? Well, my development machine is currently set to the fr-CA culture. ASP.NET MVC understands the fr-CA culture just fine and renders the dates in the format specified for that culture. On the client side thought, jQuery UI does not include the localization file to handle the date format for this culture by default, so it fallbacks to a standard format when setting an new date.
Fortunately, the fix is simple: you must set a default culture in you Web.config that jQuery UI can understand, which is en-US if no localization file is included. That will also make sure that you have the right culture in ASP.NET too regardless of the current culture of the server the application is executing on.
If you want to handle other cultures you must download and use the localization files from the jQuery UI at https://github.com/jquery/jquery-ui/tree/master/ui/i18n. For my project, I decided to force everything to en-US for now since the date format should be the same regardless of the culture of the browser of the user. This is to avoid confusion if multiple users with browsers set to different cultures are using the application to plan an event together.
A few closing notes
Don’t set the type of the input text box to the HTML5 date format, leave it as a standard text box. Otherwise, Chrome will use its own format for the date and you will get the following error when posting the form: The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
I also looked for the problem in the wrong place for quite a while: I usually submit values to WebAPI instead of submitting an ASP.NET MVC form, and WebAPI uses a different parser for dates.
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.