Corlew Solutions Principles of Software Development
prin·ci·ple - A fundamental doctrine or tenet; a distinctive ruling opinion.
Unlike moral principles which are eternal & universal, software development principles are still being discovered & refined. As computer hardware and information technology evolve, the principles that guide programmers on how best to develop software evolve with them. The principles below have been learned by developing applications of all sizes over a period of many decades. They are the product of informal water cooler conversations, entrenched ideological battles, a lost bet or two, reading & learning from the masters and day long debugging sessions.
#1 - Don't Repeat Yourself (DRY)
Functionality should be defined in a single method, module, object, etc...
When functionality is repeated across methods or objects it suggests the application has been poorly written. Every line of code in the application is one more line that has to be written, tested, integrated and maintained. Defining code in a single place improves system stability, readability, maintainability, clarity, and simplicity.
#2 - Minimal Methods Man
Methods or functions should be as small as reasonably possibly.
Well built software tends to have small units (functions, methods, subroutines, etc...) that are focused and concise. When code is broken down into their essential pieces, they can be easily combined into more powerful functions that are also well defined and easy to maintain. These methods can in turn be encapsulated into structures or objects that are themselves well defined and able to interact successfully within an application. When a developer embraces the DRY principle above, code will naturally simplify and become more resuseable.
#3 - Patterns Are Our Friend
Patterns should be fully embraced by all developers and used as much as possible; there are no drawbacks to using the right patterns. (Using the wrong pattern is, of course, another matter.)
Patterns are created when developers find themselves making the same decision over and over again. For example choosing to name methods in the following manor "my_method_name", as typically done in the Ruby programming language, establishes a very clear naming pattern which can be used to build consistency across applications. Patterns exist to help simplify complex problems by tapping into the combined design and problem solving skills of experienced developers. By using accepted patterns, code becomes easier to write and problems become easier to solve. In addition, code becomes easier to read and maintain since common patterns are often well understood by the development community and tutorials & support are readily available.
#4 - Every Pixel Is Important
Pay extra attention to the User Interface of an application.
A sloppy user interface disgraces the entire development team and screams, "WE DIDN'T CARE ENOUGH ABOUT THIS APPLICATION OR OUR WORK TO MAKE IT LOOK RIGHT." It doesn't matter how great the functionality is, users will grow to distrust an application that doesn't look like it was built with care or the user in mind. Most people will rightly assume (whether the consciously recognize it or not) the entire application has problems if the UI has problems.
The converse of this principle is true as a well; a great User Interface cannot compensate for a buggy application.
#5 - Learn New Technologies
Developers should constantly learn new languages, techniques, tools & libraries.
The alternative is to be a developer who refuses to gain expertise, innovate and provide more value to his team & clients. Don't be that guy; be the guy that replaces that guy.
#6 - Integrate Continuously
Integrate changes into the main code base as soon as possible.
In the "bad old days" of Software Development, programmers (or teams of programmers) would code their sections of an application in relative isolation and then start the process of merging their individual pieces together to form the final product. This "Integration Phase" was fairly painful and usually required rewriting large sections of code and lengthy debugging sessions focused on tracking down obscure integration related bugs. Fortunately those days are long gone.
Developers have learned that it is far better to make small, well defined changes and then merge/integrate those changes back into the main repository as soon as the code is ready. This mentality completely eliminates the need for a messy integration phase and improves testing/stability since other developers will uncover bugs as they are using the code. Modern Source Code Management (SCM) tools make Continuous Integration a no-brainer.
#7 - Performance Tune ONLY Where Needed
Performance Tuning an application should be limited to those areas where improvements can significantly help the user experience.
All too often developers rush to improve a method, that while slow, has no real performance impact on the user experience. While it may be tempting to do some light refactoring to make a method faster, many developers will degrade readability and stability in the name of making a subroutine 1000 times faster. This is great when the run time of a method drop from 1000 seconds to 1 second. It's a waste of time and money to improve the run time from 0.00000000000001 seconds to 0.00000000001 seconds.
#8 - No Programmer Is An Island - Follow the Style Guide
Style guidelines help teams of developers build a more consistent, readable and maintainable product.
It is true that Software Development is as much an art as it is a science. Developers should have some freedom to develop in a way that is efficient and natural to them, but most developers work in teams and those teams need to be efficient as well. The style guide is one tool that helps ensure an application has a consistent feel. It can serve as a vehicle for experienced developers to share their wisdom with junior developers and it can greatly simplify the readability and maintainability of an application - especially when using languages that aren't particularly clean or when working on large applications.
The style guide can be created through debate amongst the development team or it can be provided by a senior developer. Once the style guide is established, all developers must follow it and changes to the guide must be approved by an authority. Rogue developers who deviate from the guidelines should be tortured, mocked or flogged until they embrace correction.
#9 - Minimize the Style Guide
Style guides should be as small and as loose as possible.
While style guides help make application code more consistent and provide direction for less experienced developers, they can also make development harder for programmers when they become too onerous. Nobody will read or implement long drawn-out style guides so it's always better to target what really matters and keep the guidelines as succinct as possible.
Since good software development is partly an art, developers need the ability to express themselves in a manner they find natural. However, structure and consistency across an application is important as well, so a proper balance much be achieved.
#10 - Test Within Reason
Testing takes away from development resources, so test as little as needed.
We will always have software bugs with us; it's inevitable since software relies on fallible human beings. The goal should never be to eliminate all bugs in an application because we can never know that we have found them all. Instead, focus should be placed on testing the main use cases and building a well designed application that can easily be upgraded when bugs are discovered.
Test Driven Development and intense testing phases absolutely may be necessary for some types of applications (like mission critical systems), but for the average application it's overkill.
#11 - Write Self Documenting Code, Comment What's Missing
Write code that reduces the need for comments & documentation.
A competent programmer will be able to read clear, self documented code and understand the functionality. Comments that restate what can already be understood directly from the code are at best worthless and at worse, wrong or misleading. Most good programmers will remove the clutter by deleting superfluous comments. Having said all of that, there are situations where comments can be useful:
- Background information: When developers examine a piece of code, they become very interested in why certain coding/design choices were made. Good developers will recognize unclear code and leave a comment explaining why it was the best choice at the time. Explaining why you thought it was necessary to modify the contents of an array while iterating over it might not save your rep, but having some background information will help developers understand the code better when it comes time to debug or refactor.
- Non Obvious Effects: If you know a piece of code does something that isn't readily apparent, it's usually a good idea to leave a note so future developers can account for the functionality.
- API's: Comments in API's are useful to 3rd party developers who are mainly interested in how a particular method can be used. Documenting the allowed inputs on API's helps users of the API understand the API without having to dig through the code. Well named, self documenting API's are encouraged, but comments can be particularly helpful in this case.
"Obey the principles without being bound by them."
Programmers should strive to maximize: