Any of you who have been reading my site since the beginning might remember I wrote a post about the importance of forcing yourself to reinvent the wheel. I still stand by that, but that doesn’t mean I am entirely against all frameworks. In fact, in the case of scripting libraries, I can definitely see the value in using them. The key point is to be able to tell when to use a library and when not to.

Why Should You?

One nod for using libraries and frameworks is that reusable code is a good thing. It saves you time and money, and I think most developers have at least some amount of code that they reuse on various projects. I am all for that. We programmers are lazy…errr…efficient. If we can create a solution that is flexible and reusable…then more power to us.

Libraries are also quite handy in large teams. They provide a common base for everyone on the team to start from, and if you stick to a certain naming or formatting convention, in combination with a library of some sort (either in-house developed or not), you can make communication very easy and eliminate a lot of the questions that can arise when passing code from developer to developer.

Large applications also provide us a good reason to use a library. In Javascript, for example, there are a fair amount of browser incompatibilities. These incompatibilities are taken care of by most Javascript libraries, allowing a developer to focus on developing the actual logic for the application not the browser differences that arise.

On the Other Hand…

There are many issues though that can arise from consistent use of libraries and frameworks. If you use a library exclusively, you can become quite dependant on it. It’s important to understand the underlying code that the library is using. If you continue to depend entirely on a library to cover all browser bugs for you, there will come a time when there will be a bug it doesn’t cover, and you aren’t going to know where to turn to troubleshoot it.

Also, and this is particularly true in CSS frameworks, you can become too attached to what the framework provides and start conforming your code to fit in with the framework or library you are using. There is a saying that goes “When the only tool you have is a hammer, everything looks like a nail.” If you are using a CSS framework to create your layout and there is a particular visual style that the framework doesn’t quite get right, the most common approach, unfortunately, is to conform to the framework. You start to look for ways to make the layout fit within the frameworks provided structure.

Continuing with CSS frameworks, there is also a definite lack of semantics. You end up with mixing content with presentation by providing HTML markup that uses classes like yui-gb or span-8. I understand that semanticity is not no everyone’s top 10 list of important things to do (though I do feel it should be a priority). But if semantics aren’t particularly important, why not just use tables to mark up the page. It would take less code and would work almost seamlessly browser to browser. (Please note, I am not in any way condoning the use of tables for layout…I’m just making a point.)

For those Interested

So, in case you’re wondering…here’s where I stand on using libraries and frameworks. For Javascript, I occasionally use a library for code, usually on larger apps. Most of my code though is hand-created, however I do try to build with reusability in mind. I guess you could say I have my own personal library that I use.

As far as CSS goes…I don’t use frameworks and can’t see a time where I will actually do so. The lack of semantics rubs me the wrong way and to be honest with you, most of my CSS is not that similar from site to site. That being said, I have used reset styles of some sort on most projects, and there are a few other basic styles that I tend to include on all of my CSS, but it’s no more than a few lines. It doesn’t take me particularly long to get a layout set up in CSS, so I don’t feel like a framework would help increase my efficiency in doing so.

That last paragraph sounds a bit harsh…but hopefully you understand that that’s just one man’s opinion. Again, I am not opposed entirely to frameworks and libraries; in fact as I said above I have used Javascript libraries in particular on more than one occasion. I just think it’s important that frameworks are used only when appropriate and as enhancements to your coding abilities…not the foundation for them.

The 5S System is actually a Japanese improvement process originally developed for the manufacturing industry. Each of the five words when translated to English began with ‘S’ hence we call it the 5S System. Like many good philosophies however, the 5S System can apply to a variety of topics. For example, the 5S System has been applied by the Hewlett-Packard Support Center in a business context and has resulted in improvements like reduced training time for employees and reduced call-times for customers. By using the system applied to coding, we can make our code more efficient and much easier to maintain.

Seiri (Sort)

The first ‘S’ is Seiri which roughly translates to ‘Sort’. Applied to the manufacturing industry, the goal of sorting was to eliminate unnecessary clutter in the workspace. The idea here is that in a workspace, you need to sort out what is needed and what is not. If you eliminate all of the items that are not necessary, you immediately have a workspace that is cleaner and thereby more efficient

Applied to coding, this can mean going through our code and determining if we have any lines of code that are really just taking up space. This can be things like error checking that has already been done at a previous step, or if working in the DOM, retrieving the same element in more than one function, instead of simply passing a reference to the element. This definitely applies to CSS code as well. There are very few stylesheets in use that don’t have a line or two that are really just unnecessary because they either accomplish nothing different than the user agent’s default behavior, or are being overridden elsewhere.

Seition (Straighten)

The next ‘S’ means to straighten or ‘sort in order.’ This step involves arranging resources in the most efficient way possible so that those resources are easy to access.

For coders, this means going through and making sure that functions and code snippets that are related are grouped together in some way. This can be done by a variety of ways. If you are working with server-side scripting, consider placing related code together in an include. In CSS, use either comments or imported stylesheets to separate style declarations based on either the section of page they refer to or the design function that they carry out. (Typographic styles in one place, layout styles in another). In object-oriented programming, organize your code into logical classes and subclasses to show relationships.

Seiso (Shine)

The third step laid down in the 5S system is the Shine phase. This involves getting and keeping the workplace clean. This is an on-going phase that should be done frequently to polish up anything that is starting to lose its luster.

As we go back and work on code, we can often start to get lazy and just throw things wherever and use messy coding techniques because it’s quick and dirty. The long term result of that though is unorganized code that is difficult to maintain. The phase requires a bit of discipline, we have to be willing to keep an eye out for portions of our code that are becoming a bit unwieldy and take the time to clean it up so 6 months down the road we aren’t pulling out hair trying to remember what the heck we were thinking there.

Seiketsu (Standardize)

The Standardize phase involves setting down standards to ensure consistency. We can apply this to our coding and make it much easier both for us in the future, and for new employees who may have to try and work with some of the code we have developed.

Standardization in code can come in a variety of forms. We’ve seen some standardization in coding for-loops for example. In a for-loop it is very typical for people to use the variable i as the counter variable throughout the loop. Coders of various levels of expertise recognize the variable i in those situations very quickly and easily, because it is used so frequently.

You can also standardize the way you format your code. Some people prefer to indent code inside of loops or functions for readability, others don’t. Whatever the case may be, be consistent with it. Having a consistent coding style makes it a lot easier to come back to that code later and be able to quickly locate where that new feature needs to be dropped in.

Shitsuke (Sustain)

Finally, our last step is to sustain the work we set down in each of the previous phases. This is perhaps the most difficult phase of all because it is never ending. There is a definite level of commitment to the process that has to be displayed here in order for us to continue using and utilizing this process when we code. We can’t be satisfied with doing this once or twice and then letting it go. If we work to continually implement this process, we help ourselves to create more manageable and efficient code from the start of the development process to the conclusion.

I am a huge fan of basketball, and find the history of the game particularly enjoyable. One of the basketball figures from the past that I have always admired the most was John Wooden, who coached the UCLA basketball team to 10 NCAA national titles, including 7 in a row at one point. He had four 30-0 seasons, and at one point his team won 88 consecutive games. Point being…the man was quite good at his job.

Each year, Wooden started out his season by having all of his players come into the locker room for his first lesson. He’d sit them all down, then pull out a pair of socks and slowly demonstrate the proper way to put them on. He’d roll the socks over the toes, then the ball of the foot, arch and heel, and then pull the sock up tight. He would then have the players slowly run their fingers over the socks to make sure there were no wrinkles. Seems kind of trivial right?

However think about it for a second…if he put that much attention into ensuring that such a small task was carried out so precisely, wouldn’t it follow that each task his team performed would be given the same kind of thought and attention to detail?

It’s that way with programming and design as well. If we think details like semantic names, using progressive enhancement, and consistently formatting our code are important, won’t we also be concerned with much bigger details like making sure our code is efficient, our program is easy to use, and our design is effectively portraying the message we are trying to send?

And what if we do decide that some of these “trivial” details are not important enough to worry about? Where do we then draw the line between what matters and what we can just kind of ignore? If it’s ok to not use meaningful names for our variables, is it also ok if our code takes a few more seconds to load, or if one of our scripts is not unobtrusive? When does something become important enough to matter?

It may seem somewhat trivial to make sure that all our identifiers in CSS are meaningful names, and that in our programs we always format our functions the same way. However, if we put that kind of attention into all the little things that go into programming and design, just imagine the high quality finished product we will have. It is that attention to detail that separates the good programs from the great, a good looking design from a “wow” design.

That’s why we can never sit still. We need to always push ourselves to find better solutions…more efficient code, more effective design. Just because something works doesn’t mean it works well. Only by taking time to pay close attention to the “minor” details that go into our development process can we be sure that our final, finished product will be one of high quality and durability.

Unfortunately, this is often a total mess of a job. The code we have to work with is often quite long, poorly documented, looks like ancient Greek, and leaves us angrily spewing silent (perhaps in some cases not so silent) insults at whoever the poor person was who created this mess. Not only does this leave us frustrated, but it also can frustrate our employers, as projects that should’ve been easily taken care of now require much more time and effort.

Here then, are a few practices you can start using now to ensure that the next guy working on your application isn’t hoping for your demise.

Start Commenting

This is one practice that should be ingrained in your head from your early on in your development career. In addition to making the code easier for you to navigate in a month or two, effective commenting can also make it much easier for a new developer working with your code to understand what is going on. Any section of code that may require more explanation (functions in particular), should have a comment explaining what is going on there.

It can also be useful in some cases to explain why a particular solution was used instead of another one. If when developing, you found that one solution resulted in better performance than another, comment about it. A person just trying to understand your code may not realize that there is a performance benefit to your code, and ditch it in favor of something he/she is more familiar with.

Use Descriptive Names

Few things are more frustrating to someone trying to work with your code than coming across blocks like this:



Granted, a simple for loop like above is not to difficult to follow, but what exactly are the variables, a, j, and x? This may seem to save you some typing initially, but coming back to this in a few months will drive you crazy. Variable names should make some sense.



Just by using better variable names, we have made the code much easier to understand. Even to someone completely unfamiliar with your application, it is easy to tell that we are looping through a bunch of employees, and counting how many of them have a first name of ‘John’. Not so easy to tell in our first example.

Be Consistent

This goes for naming conventions as well as formatting. Come up with a set way of naming variables and stick to it. Don’t have my_variable on one line, and then otherVariable on the next. If you are going to use underscores, stick to underscores. If you want to use camel casing, then use camel casing on each of your variables. It makes it much easier to tell at a glance what values are variables in your code.

When you are declaring functions, decide how you want to display them. Some people like to use the following format:



Others will use stick the opening bracket of a function on the same line as the initial declaration.



It doesn’t really matter which method you use, just so long as you continue using it throughout your code.

Utilize Common Design Patterns

Design patterns are solutions to specific programming problems that have been documented and allows developers not to have to solve the problem again and again. They provide us with a way of quickly communicating the method used to resolve a problem. Common design patterns, like the factory pattern or the singleton pattern, have the added benefit of being used by programmers of various different languages. Now anyone who recognizes the pattern used can tell right away what is being done, it’s just a matter of figuring out the exact syntax of the specific language being used.

Be careful with this one though. Don’t just use a design pattern to be using design patterns. If you make sure your code can benefit from the use of a design pattern, then go ahead and implement one. Otherwise, you will just end up with over-engineered code that is more complicated than it may need to be.

Make it Flexible

Make sure your methods are flexible and can be used in a variety of different ways. You never know the different uses that may be required of your application in the future. Make sure your methods are built in a way that the data returned is then able to be used in various solutions. For example, let’s look at some very simple Javascript that involves getting an employee’s name and outputting it to a div.



This works perfectly fine for our solution. What happens though if in 3 months, we decide that we actually want to use the name in an alert instead? Now we have to go back, find our getName function and rework it. Instead, if we make the getName function more flexible, we can allow future developers to use it however they choose.



Separate the retrieval of information from the usage of it. It makes the code more flexible, and much easier to adjust in the future.

These are just five simple techniques you can use to ensure that your code is easier both to understand and to adapt for the next guy who comes along and has to modify it. It also has the added benefit of making your life a little easier when several months down the road, your boss tells you to change some of the functionality. It is now easy to both understand what the code is doing, and how to make it do what you want.

While he admits in his comments that he was mainly venting against as he calls them “weak build-it-yourselfers” I thought it brought up an unfortunate opinion that at times seems to rise up in this industry. Now please note, I am not trying to pick on Guy Davis at all. There are some very valid points raised in his post, and as I stated before, he does admit he was mainly venting. I am sure all of us have vented about such things before.

Developers sometimes give a cold shoulder to developers whose code is not up to par. This is an unfair judgment though. Particularly in an industry as fast moving as the web development industry is, you cannot afford to wait until you are an “expert” to code. You have to code using the best ways you know how, and continue to learn. This means that there are undoubtedly some projects you wish you could pretend you never touched. I know I have them.

I think that a better classification is to broaden it out a bit and say there are two kinds of developers. The first kind are those that are content just getting the job done. They are not particularly concerned with how it is taken care of, so long as it functions relatively well. If they have to use inline Javascript to create an effect, then so be it. They don’t push themselves to learn more and find better ways of doing things, they just accept that what they do works well enough and why would they ever need to progress further.

The second type of developer, however, is never satisfied with where they are at. Yes, they will use the knowledge they have to get the job done, which results in some unseemly coding at times. But they know that they have more to learn, and are constantly pushing themselves to find a better method of doing it. These are the types of developers that push the industry forward. They will take their bumps and bruises along the way, but they will continue to further their understanding and knowledge of whatever skill it is they are using.

This doesn’t mean that they always develop the solution themselves, or never use libraries or frameworks. Sometimes the best solutions are libraries. It simply means that this kind of developer is always wondering, is there a better way to accomplish this.

Therefore, I say if you are new to a language, be it CSS, Javascript, PHP, or whatever else, don’t be ashamed of the code you produce. As long as you are trying to learn more and come up with more fool-proof and efficient ways of developing, there is nothing to be embarrassed about.

If you asked some of the biggest names in web development today if they had ever done a project using coding methods they aren’t exactly proud of, I am sure the answer would be “yes”. If everyone thought that someone smarter out there would develop a better solution, the industry would become quite stagnant.

I can see their point, and in some situations, I agree. If you are on a tight deadline for a project, you often don’t have time to develop that functionality from scratch, and it therefore makes more sense to adapt the structure already developed by someone else.

I do feel, however, that web developers do need to try and create an effect from scratch when they have the opportunity. There are a couple reasons why I feel this is the case.

First off, by forcing yourself to create that layout using CSS, or that form validation script in Javascript from scratch, you force yourself to analyze and learn the intricacies of the language you are dealing with. This knowledge will help to increase your understanding of both the concepts and techniques involved in arriving at a solution for the task. And as far as I know, more knowledge and understanding is never a bad thing.

The other main reason for creating something yourself is because you never know how another point of view may help to create a superior solution to a common problem. Challenge yourself to see if you can improve the solution. I guess you could call this ‘modifying the wheel’. If you are going to try and develop a better solution, you should study the ones already out there. Try to see their strengths and weaknesses, and see how you can improve the weaknesses while not losing the strengths.

So over all, I say go ahead and reinvent the wheel. Challenge yourself to create a better solution, and in the process, increase your knowledge. Remember, the first wheels were stone slabs. I tend to think the wheels currently being manufactured for cars, bikes, etc. are probably a little bit better solution.