Building Good Web Applications

It's not what you use, it's how you use it.

Posted 11 months ago by Tom Maiaroto.

I'm in a writing mood, so this one is a bit lengthy, but I'll try to organize my points. I want to later, one day, revisit this stream of thought and break it down into some good tips for people. I've been talking with a bunch of people recently who all are in the motions of building software. Some already have some software built while others don't have anything yet. However the common thread here is that they need a product up ASAP or they need to implement more features. They need this to attract investors, acquire users, or otherwise grow.

Now, without a web site/app you can't have any users, right? You can have measured interest (another very important thing to understand which I won't go into now), but you can't have any users or visitors. So for the folks without a "prototype" (an idea I reject when it comes to internet applications - there's no need or room for prototyping, again a story for another day) or a web site at all really need to get going here. People with an existing site/app, they need to expand upon it swiftly. Both situations can really present a lot of anxiety.

The folks without a product may be in the better position believe it or not. They have a blank canvas and if they put together a good strategy up front, it could save them from many perils down the road.

What is a "Good" Application?

So how do we go about building a "good" application? Ask most developers and they'll dig into the problem by telling you to use a specific language, database, and/or other technology. This is wrong. This is a developer who is merely selling you on their personal preference. A programming language, database, or any other piece of technology does not solve any business problems on its own.

It's how we use and combine different technologies that make for "good" applications. So, for example, is PHP any better than Java or .NET? Or vica versa? If you asked developers to pick the "best" language out of line-up, you'll get many different answers with different reasoning. At the end of the day, there will be a language that's the best fir for what you're doing...And don't be surprised if there are many languages that fit the task at hand just as well. So don't play into that timeless game of which language is the best. There wouldn't be so many if there truly was one divine language.

So a "good" web application is:

  • Easily maintainable
  • Organized in its code base
  • Testable (even if you didn't write the test cases)
  • Scalable (business and user demand)
  • Flexible

It has very little to do with the language or database you use. If used properly; any language, database, or technology could satisfy all of the above.

You'll hear a lot of buzz words and I'd like to avoid the hippie language if I can. I don't care if you want to call it a "sprint" or a "jog" or a normal week at the office. The one phrase I will use here is "rapid application development." 

If you understand the principles behind programming frameworks and tools built to assist your development speed and flexibility...Then you're above the heathen who argue about which language is better. If not, you need to start learning. I can't being to express how important the above bullet items are. They literally can sink entire companies, products, and teams of employees.

Maintenance & Organization

So let's tackle this first. You'll want to ensure the technology you're using and the code base is well organized. For a quick example let's talk about the web application servers. You'll want to ensure they are all the same because when you go to flip on new ones, you want to spend as little time configuring them as possible. That wastes time and money and when you really need the extra juice in a pinch...Your window is quite large. 

Cloud hosting makes this easier, right? We can make images of severs and easily flip on more servers to scale (user/visitor demand) in a matter of minutes. Whereas if you had to setup a new server from scratch, it could take a few hours to bring on more juice.

Database. I'll quickly touch on the matter of databases here. I love MongoDB, but that doesn't mean you couldn't get the job done with MySQL or Couch Base or Cassandra, etc. What matters is that your database doesn't hinder you from accomplishing any business goals. Each of these databases can scale by adding multiple. So you're not "stuck" in that sense. In this case, unlike perhaps the RAM and CPU in your server, "speed" is not what you need to be focusing on. It's, again, organization of data and maintenance.

Code. The most important thing for your application. You'll want to ensure your code is well organized so that multiple programmers can work on it with ease. If you don't follow any convention, you will have -- not might have, you will have -- different developers building things in a different manner. There's just simply too many ways to make something work.

Often times we'll use frameworks to help guide us in code organization. You'll see the acronym "MVC" a lot for example. MVC doesn't make your application faster - it makes it more organized. Though you'll hear developers just say, "it's better" because it's long to explain how it works. Don't let that mislead you into thinking anything other than organization.

Sometimes, if we're crazy enough, we also invent new languages to solve the organization and maintenance problems. Like Google for example. They created "Go" to solve some of their challenges and keep everyone on the same page. It just so happens to be a pretty awesome language, but that doesn't mean you should race to go use it and that it's better than everything else out there.

Likewise, there's many frameworks out there as well. The important thing here is to choose a language and/or framework one that works best for your goals and keeps your application organized and easily maintainable.

For an example, if you use custom code not build on top of some sort of convention or framework, you have a few major issues or challenges.

  • Training time for new employees
  • Different conventions in different parts of your code base (which typically means that only "Bob" is going to know how to touch that and all other developers run for the hills -- this does not help you)
  • The time it takes to track down bugs is likely increased
  • Development speed is hindered

To sum this all up, if your code is not organized and it's not easy to maintain -- you will spend more money in developing your application/product and it will take longer. Like I said, this can make or break businesses. However, a developer would never know that nor would they be thinking about that. They likely don't even have an interest because those employees aren't stake holders.

Let me quickly touch base on a stigma here too. There's a common stigma that developers are lazy or that anyone can just "press a button." That's not the case. It's a very technical field (no matter how easy some of us may make it look). While most of it boils down to organization (Ever see a developer who keeps a really messy work area and/or kinda has that certain odor about them? How organized do you think they are?), it's not that developers are lazy. It truly depends on the environment that they are placed into and how organized they are. A developer might be very "effective," but chances are they are working hard. Often times that's not their fault either. It can often be a business or management problem (though of course there are lazy people out there in general, no matter what the job position is).


I'll quick touch base on what this means. What it means is that your code is covered by other code that ensures it is properly functioning. So when a change occurs, you can "run" tests to diagnose and see if something breaks. 

This outlines problems early on and makes it easy for developers to track down bugs. In combination with a revision control system, you should be in great shape here for efficiency.

Even if you haven't done a great job writing the test cases as you went along...Just having code that's able to be tested puts you in a great position. It will save time which means it will save you money.


When we sale something "scales" it actually means two different things depending on who you talk to. I often find myself having to think about it when people say the word because I have to remember who I'm talking to. If it's a business person or investor, they aren't talking about how many visitors/users the application handle before crashing. They're talking about how many customers you can reach and how much money there is to be made. Will it be enough to profitable with a large customer base? Will it be enough to support the expenses of the business, employees, and will it be enough to expand upon the services of the business?

Now, if you go into a room full of developers and start talking about "scale," guess what they're doing to think? They're going to think you're talking about adding more servers and/or databases to handle more visitors/users before things start crashing and your application becomes unavailable (which could result in lost revenue).

In truth, a "good" application needs to be scalable in both of these definitions of the word, but I'm going to focus on the technical implication.

You want to ensure the application can indeed handle many requests, but you also want to ensure it's easy to scale. Or in other words, it's great that it is possible to add multiple databases, but can your application code utilize multiple databases? If it wasn't written to take advantage of multiple servers and/or databases, then it doesn't scale.

I know you may read about the "cloud" and how things can scale...But that's not automatic. It doesn't just come with buying into someone's hosting services. The code actually has to work together with the hardware in this case. Otherwise, the application will break down under heavy usage and this could be a disaster.


Ok, last major item here. How flexible is your application? Or, if we wanted to use another hippie buzz word, how easily can you "pivot" with it?

If you find yourself not being able to re-use some code, you're likely not building quality code. Abstraction is the term developers will be most familiar with here. In other words, if you wanted to flip out one database for another, say go from MySQL to MongoDB, is your code base flexible enough to support that?

If you're using an MVC framework, there's likely an "abstraction" layer that will support this kind of change. This of course saves tons of time and money.

Aside from swapping technology, you also want to ensure your application is flexible enough to add new functionality - and do so quickly.

Startups face a huge challenge with nailing down the right features. There is a lot of trial and error no matter how good your metrics are (no not Google Analytics/visitor metrics -- business metrics). Web applications, in this day and age, need to be flexible enough to survive in this kind of environment of constant change and uncertainty.

At the end of the day, if you can't change your software to keep up with user demand, you're toast. The reality of all this is that, as a business owner, you must be able to understand the technical principles from at least a high level. I hope this has been a good primer for the non-technical entrepreneurs out there.

Good software starts with good strategy and aligning business goals with your development.

Filed under
comments powered by Disqus

Search for Posts

Popular Labels

social media virality score general internet web development reviews and opinions php web tools hosting lithium web design

Recent Posts