poniedziałek, 30 listopada 2009

Developer checklist

Every book about project managament in software industry starts with some sad statistics that sound something like this:
According to the Standish Group in 1995, only about 16% of software projects are successful, 53% challenged (that is cost overruns, budget overruns or content deficiencies) and 31% cancelled.

Sometimes I think that it's just an excuse for incompetent project managers but let's assume that's sad true about software industry.
However, I must say that most software projects I worked on were successful in terms of customer paying for delivered software. I must admit that I've worked only in software houses and even if a client wasn't delighted he had to pay for the product.
As a developer, I'm not responsible for selling the product, I'm responsible for software architecture, maintainability and so on. From this point of view, many projects were huge failures. I don't have recipe for making successful software, but I know what leads to failure. If you don't follow this simple rules you will inevitably have lots of problems.
The rules are kind of best practices. I divided them in several sections ordered by their importance.

  1. Use version control system and more importantly learn how to use it.
    For example, if you work with SVN learn how to create branches, add properties, always write comments when commiting changes.
  2. Create centralized error/exception handlers.
    I've seen so many projects that don't utilise this functionality. Distinguishing mark of such project is the need that every developer has to remember to catch exceptions in their routines, even though they mostly don't know what to do with them.
  3. Log information about errors.
    This is connected with previous point but I want to emphasize proper error logging facility. Too many times I've seen code like this:
    public void LogException(Exception ex)
        /* some code */
    catch (Exception ex)
        Logger.Error("Something bad happened");
    If you don't know what really happened, you won't be able to deal with it. Remember, most errors will occur when application goes to production environment, not during debugging sessions.
  4. Keep security in mind.
    If you work with sql database never ever let sql injection be possible in your app. If you work with directory service watch out for ldap injection. If you create web service - secure it. Never trust user input and never assume anything about the environment your app will be working in (or assume the worst).
  5. Understand SOA if you really want to use it
    Service oriented architecture is very hard to implement properly. Many times people end up creating service that has thousands of completely unrelated methods or service that can take every argument and return every result. This is a real maintaince nightmare. What is more, if you publish your service definition it is almost impossible to change it without making breaking change. Services should be really well defined and many times it is just not the way to go. If you really don't need to publish some services to third parties don't do it.
  6. Create good testing environment.
    If you don't have testing environment that is very similar to production environment you will fail. Deployment in production environment will be a nightmare and you will not meet your deadlines. I assure you.

  1. Don't mix presentation layer with application logic.
    It is repeated over and over but it seems that people will never learn. Sometimes it seems to be easier to put some logic in presentation layer but it is always bad decision.

  1. Unit testing / automated tests.
    Personally I consider it to be very important, but I've seen many projects that were well-written and had great architecture even though they didn't contain single unit test. What is more, they had almost no bugs. That's why I put unit tests only on "may" list.

These are my rules of creating software that has smaller chance of failure. Every time I forget rules from my "must" list I have serious problems. To be honest, few times I tried just to forget these rules and tried to create some workarounds because I considered implementing e.g. central error handling a breaking change to the code. However, I always ended up fixing it because breaking the rule had such a bad impact on the application. I've learnt from these examples that creating workarounds is just a waste of time. Unfortunately, it was learning the hard way. I hope you will find the list helpful.
Happy coding.

Brak komentarzy:

Prześlij komentarz