To me, the most important aspect of application development is the database, not necessarily the product used (Oracle, MySQL, SQL Server), but more importantly the database design and implementation, including the physical layout of the database onto disks. I may be biased, since my specialty is database systems, derived from a graduate degree specialization and time with Oracle Consulting Group, but I have been on numerous development projects where the lack of in-depth knowledge and understanding of database design considerations early on in the project have caused lengthened front-end development time, performance problems and/or significant issues when site functionality needed to be expanded. To me, the database design is the foundation upon which you build your house. Do a good job with it and the entire process runs smoother, quicker and provides a better experience for the end user. If you don’t do a thorough and complete job, while you can usually start front-end development sooner, you will inevitably run into, and continue to confront, the following issues for the life of your application:

*      Database design is not intuitive and easy to understand to the front-end developers. This results in longer development times and inevitably functionality which is not complete or inaccurate.
*      Database design which includes duplication of data (e.g. in database terminology, not minimally normalized). This results in duplication of front-end work, unnecessary checking of data to ensure that all copies of the duplicate data are in sync and/or data which is not in sync, which can then cause far-reaching problems on its own.
*      Database design which has not considered performance related issues. This results in a non-optimal end-user experience. In some cases this may only be an irritation, in others it may result in the end-user never returning. Finding and fixing performance related issues can be very difficult and expensive, in terms of manpower, after an application has been built. It is far better to look at an application and attempt to understand and incorporate performance considerations into the design and implementation than to attempt to retrofit changes later.

Again, since I consider the database to be one of the most important, and usually overlooked, factors in the success of an application, the blueprint for success really, I will address several specific database related subject areas in upcoming posts.

Forming the Tech Team

May 5th, 2008

One of the core components of the project team is the Tech group. While it is easy to consider this a group of people with homogeneous skills, in reality a considerable amount of thought, planning, budget knowledge and crystal ball gazing has to go into developing the proper skillset, experience and FT/PT/consultant mix.

In most environments the Tech group will consist of operational, support and development components. In some situations, designers and a project management component will also be a part of the group.

I believe that the place to start when forming the team is by bringing out the crystal ball and looking into the future. By future, what you are attempting to determine are the on-going and continuing technical staff needs while also understanding any budgetary constraints and limitations. During the development and initial post-launch period of creating a new website or rolling out a new product there will usually be a temporary requirement for specialized skills or increased headcount of people with skillsets already on staff. However, after the initial launch, issue resolution and development of key backlogged functionality requests have been fulfilled, the site and products will fall into a steady state of support/development needs. Experience, knowledge of the company and its goals and an understanding of budgetary considerations are critical in attempting to determine what these steady state needs and positions will be.

Ideally, you want to make every effort you can to fill these long-term positions with the highest quality people you can afford, in addition to finding people who can grow and will be challenged and have a reasonable chance that they will stay with the company for an extended period of time. This is much like a three-legged stool. If any of these is out of balance with the others, it will either not be a good fit for the company or the individual, resulting in inefficiency and the need to start the recruitment and training process over. As an example, if you get an extremely technically qualified individual and at steady state the individual is no longer challenged, he/she will become restless, look for a new position where they can find greater job satisfaction and eventually move on. Conversely, if the hire doesn’t have the required skill set and knowledge and can’t or doesn’t grow into the position, you will have to make a termination and start the recruitment and training process over again. So, in recruiting, it is a fine balance and requires experience (and a bit of luck) in recruiting long term team members.

So, now that you know where you will be in the long-term, it is time to turn your attention to the short-term and augmenting the long-term team with a short-term team, probably some mix of consultants and outsourcing. There are various ways to accomplish this, but the most important are to make sure that you get high quality help, with the right skillsets and experience using the skillsets in situations similar to yours and that this team can commit to the time period you need them to do the job.

Finally, when forming the combined team, it is always my objective to ensure that the permanent team members are fully integrated (and not merely isolated and working alone) into the development process and are given tasks and roles for project components that are key to the application or are the most complex.. This eases the application support task later, once the consultants are no longer on the project and ensures knowledge transfer of the most critical components.