Oh, the books
I’m going to try to take the middle ground on this one. I want to make sure I cover the bases. But I don’t want to bore you to tears either. This will be a relatively short and sweet outline of what it’s all about so let’s jump right in.
Plan It Out Before Writing A Single Line of Code
Never just start writing code, period. It really doesn’t matter how small the application is. If you don’t plan first you will end up with spaghetti code before you know it. What is spaghetti code you ask? Well, it is code that links back, forth, and through just about everywhere imaginable. Then, when you try to refactor a portion of your code, everything breaks and you either have to leave it alone or spend months refactoring the rest of it.
UX/UI is Not Just For the UX/UI Guy to Worry About
Let’s for a moment go over what UX/UI is. UI is the “User Interface” and UX is the “User Experience. The user interface is simply what the user sees, how things are laid out on screen. The way the user interacts with the interface, how fast things load and how easily they can find things is the user experience.
When you’re developing an application you need to design a good bit of the UX/UI first. Get some mockup screens created and even get some input from potential users. Next, begin designing parts of the application like the file system and database.
To create a well-rounded application you’ll need to re-visit the UX/UI several times throughout development. Ultimately you want to start with UX/UI and end with UX/UI. When it’s all said and done, it’s all about what the user needs and wants.
Determine How Modular Your Application Should Be
When considering the best practices for application development we often hear a lot about modular design. But how modular should your design be? On one hand, you can have modules that are too big and complex. On the other, your modules can be too small resulting in needless complexity from having too many moving parts. Either way, you end up with code that is hard to maintain.
Finding the right balance takes lots of time and experience. Let’s say for example that you wanted to create an automobile application. Think about the modules that need to be created to properly describe everything that the automobile is and can do.
One approach would be to create two modules, an electrical one, and a mechanical one. As you develop this idea you will quickly realize that these would end up being too big and complex. Another possible scenario would be to break it down into smaller mods named bolts, wire, tires, rims, battery, buttons, lights, and fuses. However, that level of granulation would be more appropriate for classes and objects. They would be way too small to be modules and very difficult to maintain.
Finally, you could create modules named engine, air condition system, coolant system, and electronic control unit. This would be more balanced because now the modules are not too small or too big. For example, the “piston” class would belong to the “engine” module.
Set and Maintain Good Documentation Practices
Documentation, definitely not a favorite subject among programmers. However, it is a very important aspect of software development. On one side, you have code documentation that tells other developers and your future self how the application works programmatically. On the other side, you have the documentation to tell the user how to use the application.
There is another set of documentation that is often underdeveloped or never implemented at all. That is support documentation. The nature of this type is kind of a hybrid between technical and end-user. Depending on how complex your application is you may have two flavors of this type of documentation, T1 and T2.
T1 support docs would be for customer service representatives, no technical background necessary. They just need to know how to read steps and give instructions. T2 will cater to more technically inclined representatives. This becomes necessary when T1 is unable to solve the problem.
If T1 and T2 are unable to resolve the issue then insteps T3, these are the actual developers. Good documentation helps teams be more productive and users to get all the help they need to get the most out of your application.
Some Rules To Remember In ALL Development Projects
Some final thoughts to take with you and ponder on as you embark on your journey. First, this is by no means a complete reference on the best practices for application development. This is merely the tip of the iceberg and there are tons of books and online courses on the subject.
As an application developer, you will learn and apply many different rules, standards, and best practices. However, there are two rules that all of these hang from.
Rule Number One: “Make your customers lives easier”
The applications that you create should ultimately lead to making your customer’s lives easier. That is who you are designing and developing this for and also who is likely funding your efforts.
If subdividing the application into more manageable parts and optimizing data transfers maks your customers lives easier, do it. If refactoring the user documentation helps your customers better utilize your application, do it.
Rule Number Two: “Make your lives easier”
Rule number one and two feed off of each other. If your code is hard for you and your team to maintain you will end up with an inferior product and thus the customer suffers along with you.
Another scenario would be if you give your customers poor documentation, you as the developer will be spending more time on the phone doing the job of T1 and T2 instead of developing. See, now you’re miserable because you failed to make there lives easier.
We have looked at several different concepts in this article including pre-code planning, UX/UI, modular design, documentation, and some rules to remember. Now, take what you have learned here and go, design, and develop some rock-solid applications.
John Robinson is the owner and founder of Riivue. He currently spends his days working as a web services developer at a technology company in Tupelo, MS. John at one time played a key role in directing and growing an Engineering firm and was part owner of a Drafting and Design company.