2008-11-18

After though

After my initial though, I did not know where to begin. So I tried to write a prototype. It was fun to do. My main goal was to get the priorities of what to do first or to look for new details. After many late hours before going to sleep, I ended with a messy working prototype. Then I note some new details to add to my list.
  • Database table naming
  • Security - SQL Injection
  • Security - Cross site security
  • Controller separation
  • Prevent Tag soup (by extending the HTML Helper)
With all those nice new tough going on, I received books ordered from Amazon. Code complete 2 and Peopleware - Productive Project and Teams. I stop all coding and start reading Peopleware. I currently have read the half of it and there's good insight on how the environment we work in as a programmer could affect our productivity. I will continue to read it.

Some time have pass since I wrote the prototype and I had an horror vision about it. In the past many prototype have gone into production without major refactoring... And that's definitely not something I want to happen again. Then from horror came light; I found how to set the priorities on points I need to look for. I will begin with the ones I really don't want to be left apart first. The one that will be hard to insert later through refactoring. So I now have a new prioritize list.
  1. Test Driven Development (TDD) with Unit test
  2. Exception handling
  3. layer separation
  4. each layer role
  5. Controller separation
  6. Security - SQL Injection
  7. Security - Cross site security
  8. Internationalization
  9. Prevent Tag soup (by extending the HTML Helper)
  10. naming convention
  11. Database table naming
  12. Data access (will work with LINQ until I got to that point)
  13. Explore nHibernate (data access tool)
  14. Explore Catharsis (Application framework using nHibernate)
  15. etc.
After doing the sort, I realize that all tasks can be grouped in a few category.
  1. Development process (After it's done, you can change the way you did it)
  2. Software architecture (All the thing you want in place before writing usable functionality)
  3. Implementation standard (How things will be written to be easier to maintain)

2008-10-31

Initial tough

How to start it? After so many years extending the live of a mature software. It's now time for me to take all I learned and to applied it to a brand new generation of software. In this blog, I will keep track of the steps I'm doing to make it append. I want to document the best practice and standard to use. In the process, I want to read about each aspect, make some prototypes and summarize my conclusion.

I don't know yet all the detail I will need, but I want to follow some base principles.

  1. Simplicity
  2. Maintainability
  3. Scalability

Simplicity

I believe that when something is simple, the chance of doing it wrong is small. And when it's complex, the chance of doing it wrong is growing. So I'm looking for simplicity for the user and for the the implementation of the technology.

Maintainability

No matter how complete the initial release will be, this will be only the first step in the life of the software. I have learned the lesson the hard way with an enormous initial technical debt. This is one point I will try to illustrate with example I lived.

Scalability

I'm not a big fan of over doing the architecture process to be able to scale. I believe in delivering something working now is more important than the perfect thing in 6 months. When you have enough customers with the initial project, you will have the resources to make it scale. It's far better than having no customer at all because the project is already stretch to it's limit trying to have it perfect. However, I will be a fool to write a software with no possibility to upscale. So, I want to leave place for improvement without doing them right away.

Technology choice

I have always worked with Windows. Programming with C++ / MFC, then with c# and the .Net Framework. I have a good experience with Windows application and some with smaller project with classic ASP and ASP.NET. I have also worked with MS SQL Server. With all this experience of Microsoft technologies it feel natural to continue this path for the next project.

From the current technologies available from Microsoft, I have chose ASP.NET MVC.

  • Web model is easier to deploy than Windows application.
  • I feel that the architecture of Model View Controller is more stuctured and will beter suit the need for a comercial software.
  • RESTful application seem simpler
  • Without session state to maintain, it let more place for scalibility
  • It's the new thing ;-) It give extra motivation point...
What I will look for
  • layer separation
  • each layer role
  • naming convention
  • Data access
  • Internationalization
  • Exception handling
  • Unit test
  • etc.