When designing a new system, it is frequently necessary to make decisions about specific features to be included. Less frequently, however, one also needs to decide to remove features that are not necessary or cannot be supported by the development group.

Such decisions are important because they shape how the application evolves over time. Simplifying an existing system is sometimes even more important than adding features: a system that has a lot of unnecessary features may be hard to evolve and maintain. It may also hide an uncommon number of bugs.

Unnecessary features are poisonous for maintainability. Not only it costs more to maintain. Feature bloat also causes the system to keep bugs for a long time, simply because the affected code is not frequently exercised.

I have found over the years that, after an initial design, it is always helpful to determine what can be removed from the list of requirements of a project. This gives designers the great opportunity to consider what is really important and what is merely useful but not necessary for the central functionality of the product.

What to Remove

A number of approaches can be taken when considering such feature reductions. First of all, imagine what would be like to live without a feature. If you think a functionality is optional, just remove it from an initial release. In general, the first release of a piece of software should contain only the most fundamental functionality.

Having non-fundamental functionality in an initial release is a sign of a number of weaknesses. First of all, it probably means that you should have released the product earlier. Doing so would have resulted in additional feedback, which is always useful to improve the application. If the core functionality is not good enough, then there is no point in releasing additional features.

Releasing early is also a good way to get feedback from users on what they really want. Many users will gladly tell you what they think of a product and how it can be improved. This is the best type of feedback, because it comes from someone that has a true interest in using your software.

All things being equal, it is better to have users that will start with a software that contains only the core functionality, and have them tell you about the additional features they need. If there is interest in your product they will get back with ideas for improvement that can be introduced into the next version. On the other hand, if the core functionality of the product is not important for users, then you will probably have no real need to continue testing and improving those features.

Conclusion

Designing a complete product with lots of features may seem attractive at first, but it usually doesn’t work because you don’t know in advance the customers’ real needs. It is generally better to remove features that are not part of the core functionality of your system. This can not only save precious development time but also allow you to focus on what really matters in an application.

Design patterns exist to solve common problems found on the development of object oriented software. As such, the singleton pattern exists to satisfy the need for code that is available to the whole application. It also helps when we want to enforce that only one instance of an object exists during the lifetime of the application.

The problem with the use of singletons is that the requirements above contradict a lot of the paradigms of object orientation. First of all, if some code is available to the whole application without creating objects, it can just be viewed as a structured piece of code, which could be easily implemented as a set of functions.

If one doesn’t need to create or destroy objects, then there is no need to use an object in the implementation, unless you’re using a language such as Java that has only objects.

As seen above, singletons don’t pass the ‘smell’ test of a pattern for the creation of solid code. Despite this, singletons were once a celebrated design pattern. A lot of singletons can be found everywhere in modern code. It is necessary, however, to be aware of some of the problems you will find when using them:

• Singletons are hard to test: Since it is difficult to have any control about how the singleton is created, testing of a singleton in a controlled setting becomes very complicated. Sometimes, a singleton assumes a lot about the programming environment to work properly, and as a result it is not possible to create one of them in isolation.
• Hard to reuse: for the same reason given above, singleton’s are hard to integrate to other code. They become non-reusable because they have to assume so much about the environment of any single program.
• Allow indiscriminate use of resources: another big problem is hat there is no simple way to localize the use of a singleton. Once it is available, it can be used by the whole application, by definition. This has implications in the areas of safety, as well as in avoiding mistakes in the use of this shared resources.

Alternatives

Although singletons are in use in so many places, it is possible to avoid them in many occasions. Here are a few tactics that you can use to get rid of unnecessary singletons.

• Convert into standard classes when possible: sometimes it is not so much work to convert a singleton into a traditional class. Just make sure that the initialization is done only when the first object is created. If there is a single resource that needs to be shared, for example, a network connection, you can use a static member variable to store that resource. In this way, you can have multiple objects that are still referring to a single resource.
• Use static member functions in some cases: sometimes a singleton is improperly used when just a few static methods would work. This is a case when it is easy to remove the singleton, because there is no central resource that is shared. While static methods are not the best thing in the world, they at least are easier to test than a monolithic object.
• Determine where the singleton is used. Sometimes it is applicable to just a small part of your app. When that happens, create a class that may used only by that part of the application. For example, if you using C# that might be a class visible only to the package. In this way, you avoid the indiscriminate access provided by singletons.
• Factor the singleton into two or more classes: sometimes the options above are not available. But it is still possible to reduce the functionality of the singleton and provide them with two or more classes. A few of these classes can be non-singletons, which are easier to test. While this won’t solve the whole problem, it may simplify development and testing of the application.
• Make the singleton as small as possible: As a last resort, use the tactic above to remove all the functionality that is not strictly necessary from the singleton. Even if you cannot test the singleton in isolation, you make it very small and easier to understand. This also remove the temptation of adding even more functionality to an existing singleton.

Conclusion

The singleton pattern has a number of deficiencies that make it difficult to integrate with other programming practices. Therefore, it makes sense to restrict its use only to situations when it is strictly necessary. You should investigate some of the ideas above to reduce or eliminate the use of singletons in your code, and as a result, improve the testability of the application.

Further Reading

The Gang of Four book is the original source for everything design patterns. You should check carefully the rationale for using singletons.

When people learn to develop software, they believe that long hours of concentration and isolation are the best, and maybe unique, way to achieve high quality code. Many think that by working slowly and carefully they may be able to catch most bugs and create a solid base for the program they are creating.

This idea has some truth in it. Careful planning is a right step in the design of any software. Moreover, slow progress is necessary when you are starting as a software engineer, and still getting used to the tools of the trade, such as programming languages, IDEs, and building tools, for example.

On the other hand, for a professional, experienced programmer, acting slowly may be a sign of bad working habits and programming practices. Rather then being accepted as a necessity, a slow development pace should be avoided as soon as possible.

The reason why it is important to impress speed to your daily routing is not only because of business requirements or competitive pressure. Speed in development may also become a qualitative advantage that may provide the edge you need to create better products.

Faster May Be Better

There is a big reason why working faster may benefit you and your company. Software development requires a lot of concentration, which is hard to achieve during long stretches of time. Sometimes, you need to understand very complicated segments of code, and keep this level of concentration may be difficult to do for long periods of time.

By acting quickly, you can take advantage of short periods of intense concentration in a way that other developers would not be able to match. For example, if you can quickly fix bugs, understand what is going on in a segment of a program, and find a solution for a development issue, you will have a definite advantage over your peers and competing companies.

Creating a Quick Development Cycle

One way to use short periods of programming to your advantage is to use unit tests. Unit tests can help you to quickly figure out if the changes you made are valid and that no regressions surface. After you run unit tests, either manually or, more appropriately, through a continuous integration suite, you will have increased confidence on the results of the code you produce. More importantly, such tests can verify your code in just a fraction of the time it takes to make the necessary modifications.

It is crucial to make software easy to test. Difficulties during an initial testing phase can lead to two undesirable consequences. First, you are tempted to test less often. This leads to more bugs, as can be easily seen from experience. The other problem resulting from lack of tests is that it is harder to refactor code. Badly designed code tents to stay unchanged, and the overall body of code will not evolve as it should.

Improving Your Skills

If you want to become a fast designer and coder, you need to practice your skills. This is not different from any other profession, but for programmers this involves a lot of interplay between thinking and using automatic tools.

For example, one of the most important factors in improving efficiency is using a flexible and powerful programming environment. Such an environment should provide users with the means to create their own tools, tools that can be used to simplify common work flows.

Thankfully, most modern IDEs provide the necessary features to automate repetitive work. Also, if you have UNIX experience, you already have a world-class automation system at your fingertips: just learn how to create shell scripts to simplify common programming tasks.

For example, don’t spend time repeating the same building procedure over and over; write a script that can run that sequence for you. Better yet, share that script with other users, so that they can also benefit from your work.

An extension of the idea above is to create a complete environment that makes it easy to build and test. This usually means having a good building system in place.

Some people work needlessly for lack of a proper building system. Try to avoid this problem. You should be able to compile, test, and deploy your whole application with one step. This also means that not only you, but any developer in your group can turn a single button or key to get the software deployed.

Using the Right Tools

The other part of writing software fast is to use good tools. One of the most important tools you will ever need is a text editor. Strive to use a text editor with which you are comfortable, but that is also powerful enough for the tasks you need to complete. Traditional editors such as vim and emacs are tried and tested by some of the best programmers in the world. They are a sure way of achieving high speed and performance. If you don’t know how to use such an editor, make yourself a favor and invest time in learning one of them.

Maybe you work in a particular programming environment where an IDE such as Eclipse of Intellij IDEA is necessary. If that is the case, try to learn it well so that you can avoid clicking and doing repetitive tasks with the mouse.

Finally, get a fast machine. Hardware is cheap these days. I recently doubled the amount of memory in my working machine, and things improved a lot. It is really cheap to do this, compared to the value of the time spent waiting for programs to run. As a general guide, if you’re spending more than a few seconds building a medium-sized project, do something to change that. Either more hardware or better software will do the trick.

Conclusion

Speed is a virtue in software development. Going through shorter cycles of work, it becomes easier to validate your results, and get the necessary feedback from users. If you are spending too much time on development tasks, there might be a lot of opportunities for improvement that can make your life much easier. Learn to identify these opportunities and use one of the techniques discussed above to reduce development cycles. This will almost always lead to software with better quality.

There are numerous ways in which you can affect the correctness of the code you write as well as the capabilities of changing that code in the future. Unit testing, design patterns, and code reviews are all methodologies that have a decisive impact in how your software works.

However, very few things have such a great impact in you as a programmer as the way your code looks. This might be surprising to some people, since it is well-known that the compiler doesn’t care about the organization and cleanliness of a source file. Compilers just care about translating a stream of symbols into a binary file.

The big insight, however, is that source files are not just an input for a compiler. As important as it is to give correct instructions, the far more important role of a source file is to present the solution of a programming problem to other professionals. As such, sources files should be formatted as any other documentation: in a clean and tide way.

Software engineers are required, by profession, to create source code that solves problems. But more often than not, source code is the only form of formal documentation that tells how a program works.

The readers of program code vary in number. If you work in a large company, dozens of other programmers will, at one time or another, need to read your code. However, it pays to write clean code even if you are the only developer in a project.

The main reason is that it is very frequent that you have to revisit a decision made previously. When this happens, you need to consult source files again, and going through a disorganized program can make life miserable. Remember, to start with, that source code is by nature a difficult document to comprehend.

The other reason is that, these days, it is very rare that you will be the only person to see a source file. First, the project that you are now working on can become something of interest for other people in the future. For example, you can open source it and distribute the software to a small community. Or you may even start a business based on that application, a business that will end up having other developers.

What all this says is that it pays to be clean and thorough when writing software. Even if nobody ever see your source file again, not even yourself, think of it as training. In a future job you can expect that other people will be able to observe and understand what you’re doing.

Things to Consider

Spelling: It may seem unimportant at first, but using the right spelling has great impact on the resulting quality of source code. For example, making sure that variables are named with the correct spelling may be the difference between finding that variable or not, when using search tools such as grep. Moreover, it shows that you can communicate well and work in a professional way.

Commenting: there are many opinions about the right amount of commenting in source files. Some people think it is not necessary, while others believe you should write as much as possible. Whatever your opinion of commenting, do it consistently. Make a point of adding as much information as you feel necessary. Also, get in the habit of doing so while actually writing the code. It is too much a temptation to leave such things until after the code is done, when you will probably have forgotten a lot of the original context of the comments.

Empty Spaces: Be consistent with empty spaces, both vertical and horizontal. The most important goal is to have equal spacing everywhere in the source file. Languages such as C++ have different standards for this, for example the location of braces. Pick the method you like most, but make sure that it is applied everywhere in your project. If you’re using external libraries, however, don’t make changes to the file just for the sake of formatting: it is Ok to have external code that looks different.

Conclusion

Writing correct software is a good starting point, but is not enough. Good software is also a communications tool, and must be treated as such.

Also, writing clean code is a matter of professionalism. You cannot write sloppy code and expect be considered seriously by others. They will see a lack in cleanliness as a consequence of a lack of care — which usually is the case.

In the last few years, technology companies have started to rely more and more on open source software. From startups to old, established companies such as IBM, everyone is taking the open source revolution as an opportunity to use software that is supported by a world-wide community of programmers.

The reality of free software is that it makes it much easier to compete with Microsoft. With its closed source operating system, Microsoft is practically the last big company that rejects open source at the core of its products. While Microsoft has allowed its customers to use and share some of the open source code created inside Microsoft, the company itself has not deviated from its original path of creating a closed source ecosystem for programmers.

By their own design, Microsoft decided to create operating systems and libraries that are entirely proprietary. It is in their genetic code to do software themselves, and not trying to leverage efforts from somebody else. After all, the whole goal of Microsoft is to shape software people use, not to follow what somebody else is doing, whatever the origin of the code is.

But not everything is good in Microsoft’s world. A lot of cracks have become evident, as its PC business is starting to erode. While they have a clear lead on the operating systems, business, and server software, there is a lot of competition in the consumer front.

If you think about the current situation of Microsoft, you might think that starting to use free software would also makes sense for them. After all, everyone from IBM to Apple and Google are firmly on the open source camp by now.

Making the Right Decision

One has to wonder if Microsoft is doing the right thing when it suffers from the kind of competition allowed by Free Software. Put in another way, the question becomes: is the decision to continue relying on closed software still correct when free software is being used as an strategic advantage by all other rivals: Apple, Google, and Oracle?

I think the answer is no. Microsoft initially believed that the right way to deal with Free Software was to ignore it and invest more into better proprietary code for operating systems and other system products they own.

The problem with this strategy is two fold: operating system software is now a commodity, thanks to successful open source projects such as Linux, Free BSD, and Open BSD. These operating systems are nowadays complete, well supported by major vendors (IBM, Apple, Oracle), and in many ways more stable than Microsoft’s implementation of Windows.

The other reason is that open source is always evolving due to their fundamental nature. The best ideas in operating systems, database design, and any other system software are being implemented right now for these free systems. That has been true for as long as UNIX exists, but it has become much more important now that these operating systems are commercially supported.

While this happens, Microsoft has to do the same by themselves, without the possibility of directly using free software. This can be viewed as a competitive disadvantage that increases costs and reduces opportunities.

After more than 20 years of free software use, it has become evident for many technology companies that using free software is a strategic advantage. A company can nowadays benefit by using as much as needed from free software in order to create a custom product in record time.

This is how products like the iPhone and the iPad could be crafted without the need to write a completely new operating system from scratch. Microsoft hasn’t that ability, even though it controls Windows. They need to pay an inordinate development cost in order to maintain their closed systems. Every iteration of Windows has to be done completely in home, and doesn’t benefit from software written by others.

While the current situation can be sustained by Microsoft for the near future, I imagine that it will become more and more a hindrance for it future growth. They will finally need either to open source their software in order to achieve similar advantages, or to start using existing free software the way their competitors are doing right now. In other words, I think we are not far away from a time when Microsoft will roll out their first Linux and/or BSD based products.