The Development ‘Team’

November 12th, 2010

We’ve all seen, maybe been involved in, an organization where the first tech person , either a co-founder or brought in by the founders, is a front-end developer. On the surface, this sounds like a good idea because it is this person who has the background and ability to develop an application that everyone can see and perform the functionality requested by the founders.

While this may work out in the short-term, it may not work out for the long-term.

To understand this, I think it is important to fully understand what technical and usability factors are critical to the long-term success of a start-up’s application.

  • Functionality – First and foremost, the application has to do what it is intended to do. This is why a font-end developer is brought in. This person can make it happen.
  • Design – The site and application has to be aesthetically pleasing and have an eye-catching, functional design.
  • Performance – The site has to perform well and have good performance. For me, this always starts with the database and includes deciding on a front-end development framework that is solid and capable of growing with the company.
  • Designed and built with both short- and long-term business objectives in mind. While the first build of an application may capture the initial concepts of the founders, the application should also be designed from a functional point of providing an easy path to incorporate the growth concepts envisioned by the founders.
  • Usability – In addition to having a nice graphical design, the site has to be designed from the perspective of the end-user, keeping in mind the ultimate objective of the site, whether it is to make it easy to buy something or to ensure that ads are seen.

Let’s start then by looking at the skill set of the front-end developer. First, this person probably has excellent development skills in the selected development platform, PHP, .NET, Java, etc. He/she also probably has at least decent back-end skills, the ability to query the database and create tables. He/she also probably has picked up a minimum set of graphic design skills and a minimum of business analysis skills to gather requirements for the application’s functionality.

However, from my experience, while this skill set is serviceable, to really build the application that everyone is hoping for, it needs to be supplemented with the skills of some specialists.

  • Performance – While the ability to create tables gets you part of the way, there is a skill to database design that keeps performance, ease of development and incorporates either planned or sometimes unanticipated functionality in mind. In the end, you get an application that provides the performance and solid platform for the company’s growth if done right the first time. To do this requires the skills of someone who has a background in database design and experience doing that. The worst thing that can happen is to have to rip an application apart and start over in a year or so because of a poor database foundation.
  • Site graphical design – We’ve all seen sites that look pedestrian and sites that are eye-catching. The eye-catching sites are done by people who have a background in graphical design and specialize in creating eye-catching sites. You can skimp here, but you can also spend a little money to develop something everyone will be proud of.
  • Short- and long-term business objectives. Again, this is a subtle skill that is gained through experience. We’ve all been involved in projects where an application is developed exactly as specified, but in the end wasn’t what was desired. It is the analyst’s job (whoever may fill this role), to not only hear what is said, but to attempt to get inside people’s minds in an attempt to find out what they are really trying to say. Building the foundation and understanding the functionality from the beginning is a lot easier and cost effective than having to rip things out and trying to incorporate additional features and functionality later.
  • Usability – It is important to take a step back and look at how an application will ‘flow’ from the perspective of an end-user. Again, we’ve all been to sites that were difficult to understand or navigate and therefore left and went somewhere else. There are people and consultancies which specialize in site design from the usability and end-user perspective. It can only help to bring them on early in the process. One note in this area is that I’ve received proposals from firms that specialize in this type of work that have been what I consider to be extremely comprehensive (and therefore expensive) to what I consider reasonable. Therefore, I’ve found that you have to have a good understanding of what you want to accomplish and keep the proposal limited to that, otherwise you will end up with a large bill at the end.

So, for me, I agree, you can start with a top-notch developer. However, the development skills need to be supplemented, and supplemented early, with the skills of some specialists on a project basis to ensure that you get the application and functionality that everyone wants to see as the end result.

Database Constraints

November 22nd, 2008

In my last post I discussed Application Wide Data Integrity and how it was important that the business rules to ensure data integrity were captured in the database.

Using database constraints is the preferred method of defining ways in which the integrity of data in a database can automatically be enforced.  In essence, constraints define rules regarding permissible values that are allowed in columns, they define the rules that define interrelationships between tables and can check and modify the data in a database.  They provide the ability to assist in applying business logic to the application at the database level – to centralize and simplify it to make the development of database driven applications easier and more reliable.  Constraints are, in reality, restrictions on the data that can be placed at either the column or table level.

At a very high level, there are three types of constraints:

* Entity Constraints
* Domain Constraints
* Referential Integrity Constraints

Entity constraints are constraints on a row within a table.  The two types of Entity Constraints are:

* Primary Key
* Unique

Essentially, the Primary Key and Unique constraints allow you to enforce uniqueness within a table at the database level.  Examples of where this is important might be in the use of Social Security Numbers, customer id’s, transaction id’s and order id’s where it is imperative that one and only one instance of each of those exist within the database.

Domain constraints are column level constraints and could be against one or more columns.  The three types of Domain Constraints are:

* Check
* Rules
* Defaults

The incorporation of Domain constraints provides a single, central repository for ensuring that data related business rules are satisfied and helps to eliminate or reduce the creeping of data that doesn’t make logical sense into the data base.  Examples could be ensuring usernames meet a set of predetermined rules, social security numbers contain 9 digits and salary values are non-negative.

Referential Integrity constraints are used to enforce that the values in one column must match the values in another column, either in the same or a different table.  There is one type of Referential Integrity Constraint:

* Referential Integrity

The use of Referential Integrity constraints ensures that relationships between tables remain consistent.  Examples of circumstances you are trying to prevent include deleting customer records when and order record for that customer exists in another table or deleting an order record when products related to that order exist.

Again, all of these rules can, and should, also be enforced at the application level.  However, to avoid potential data related problems when developers forget, get lazy or just don’t know the data integrity rules, it is a best practice to identify and spend the time developing the rules when the database is designed.  Taking the time early in the development of the application will more than pay for itself later on.

Application Wide Data Integrity

October 22nd, 2008

Usually, due to time pressure, the analysis and design stages of a site implementation project are not given the time and resources that they should get.  It is human nature to believe that until someone is actually coding and you can see something tangible, then nothing is really getting done.  In the end management usually applies pressure in a misguided attempt to hasten the development process.  The problem when this happens is that all of the business rules, requirements and issues have probably not been identified.  This results in the possibility that one of the following will occur at some later time:

·         Having to retrofit rules and modify completed and tested code once the rules are identified

·         The complete absence of necessary business rules

·         Inconsistent application of business rules by different developers or within different areas of the application

None of these situations is good and each has the potential to cause lost time, frustration, duplicated effort and the possibility of inconsistent data and upset end-users.

While I’m certainly not advocating taking the Analysis and Design phases to the extreme, there is usually a balance and spending a bit more time on the Analysis and Design phases to ensure that the business rules and issues are resolved will pay dividends later and result in a much smoother and faster development cycle.

One estimate is that approximately 40% of all application code is exception handling (NO_DATA_FOUND, returning more than one row when only one is expected, etc.), so getting the rules correct and applied everywhere they are required within the application is extremely important.  If not done correctly, developer production is significantly decreased, errors are introduced and the development phase is lengthened.  In addition, testing becomes more complicated, debugging is adversely affected and error correction time is lengthened.

For all of these reasons I am a strong proponent of capturing as many business and data rules as possible within the database.  Yes, it certainly takes more time and since this is not routinely practiced on projects the project team may have to struggle a bit due to rustiness or lack of the required skills.  However, in the end project quality is enhanced and development and testing time is significantly reduced.  In particular, no matter where in the application data is inserted, updated or deleted or which developer performs the coding, or even which day a given coder writes the code, the data in the database will always be consistent and always follow the same rules since the ultimate set of rules applied to the data is stored and maintained from one central repository.

With this in mind, the developers of database management systems have gone to great lengths to provide the tools to ensure data integrity and consistency and avoid some of these potential problems.  Some of these tools include:  Unique Key Constraints, Foreign Key Constraints, Check Constraints and Triggers which I will discuss in greater detail in my next post.