The software development golden rule number 1 is: don't write code. Well… seems quite inappropriate to say that about a software development project! The title is a bit exaggerated and the idea behind this golden rule is that you should code only what's mandatory and linked to your business and limit the lines of code to the minimum.
The less code you write, the less time you will spend in writing code (obvious), the fewer bugs you will write, the less code you will have to document, maintain and make evolve. And the less code you will have to refactor sooner or later. This refactoring aspect is quite important and will be the object of another rule stating that any good quality code or software architecture has to go through many refactoring cycles during its lifetime.
So here are some advices to drive you to limit the code you will have to write:
Develop simple solutions. The simpler, the better (another golden rule BTW) and the less code is required. Obvious isn't it? However creating simple solutions IS a challenge. How many times have you been in the situation where you're asking yourself: hey that was obvious, how didn't I think about it in the first place? Thing is that as developers we have complex minds and are looking for the most amazing solutions, and it can become over killing and drives us to developing over-engineering solutions. Good practice is to always try to think twice on a solution and wonder if it could be made simpler. Do peer to peer code reviews with simplicity as one of the goal, presenting your work to others and having your solution challenged is a very good way to enhance and simplify your design
Linked to previous point is: always develop minimal solutions, answering a direct functional need. As passionate developers we often tend to do too much for the sake of building great applications. Yes you need to design and develop with evolutivity in mind, but wait for the functional requirements before make your design evolve and implementing more that necessary. In the mean time you can concentrate on building simpler, bug free applications and spend the remaining time to develop the unit testing code. And don't worry: new requirements will come and you will have the opportunity to express your creativity on something really required and useful, so be patient!
Reuse existing components (or frameworks) whenever possible and whenever they are not a company asset or directly linked to the business you are working for. There reusable components can open source components, third party out of the shelf components or your own components. One of the most obvious examples is the use of a GUI framework. You don't want to write a new grid component unless you have a very specific need or unless your business is to build GUI components. What you will have to care of though, is to make sure you choose stable, good quality and well supported components. So spend some time in selecting them and then reuse them in all projects where their use makes sense. Other obvious components to use are those which are related to technical, transverse concerns such as logging, dependency injection, data access and much more...
- One layer of abstraction above components is the use of existing applications or server applications. For instance (almost) no-one will develop his own operating system, or relational database system. These are obvious examples, however an apparently not so obvious one is reporting and you can see companies developing their own reporting layer where one could leverage an existing reporting solution. In the Microsoft world this is Reporting Services, part of the SQL Server services. Another example of an out of the shelf application server is Microsoft SharePoint Server, full electronic document management, collaboration, publishing (and much more) application, fully integrated with the full Microsoft application suite, especially Microsoft Office. Of course there can be a licensing price to pay, but usually the benefit and return on investment is far beyond the licenses you will have to pay, providing that… you choose the right tool for your need! So same story than for components: you should carefully take time to evaluate and choose the right set of applications for your need! But when that's done the gain is then huge.
So as a developer you should focus more on evaluating and choosing components, frameworks and applications (unless you're working in a big team and have an architecture group doing it for you, but then try to understand the choices that were done) and compose and integrate them that coding everything from the ground up. You obviously still have to write code but at another level and directly linked to your business. And it will be for you a first step toward a larger vision of software system and toward the software architect role. This also help keeping a good separation of concern in your application design (another golden rule, hey! we are starting to see a common link between all this and it probably confirm the more I will be writing on the subject!)
So that's enough for now and hope to have caught you attention and you will join me for later post on other golden rules!!
Comments