http://www.wmictcluster.org/Inormas - read about how James Leavesley and Calum Brannan met
http://twitter.com/inormasmedia - "We are a social media technology and strategy company based in the UK. Our team is a mix of experienced marketeers and cutting edge technicians."
Unfortunately, these "cutting edge technicians" weren't quite as sharp as they claimed and an independent audit of the system demonstrated some pretty fundamental issues in just about every aspect of the system.......
Here's what the report about the system they'd developed for their largest client had to say at the time [it's important to note that we've been told that some of these issues have now been addressed.]
Introduction:
The Bxxxx TV site is far too complex as outlined in the points below.
The purpose of this document to highlight some of the more serious problems with a view to providing guidance on the way forward.
Overall complexity:
Although the scope of this site is quite wide, it has been built in a way that makes the system difficult to maintain. Inormas are currently in the development phase, before people are using the site and it already slow and cumbersome - making changes will become much more difficult (if not impossible) once the site goes live.
The data structure is extremely (and unnecessarily) complex, the database contains over 100 distinct tables. By comparison, Facebook (built on the same basic code, happily supports 250 million users and all their content and applications with just 30 tables.
The system does not appear to have any design documentation or project plans and most of the code contains no comments (something that goes against all best practice). Although the system uses a framework, it uses it poorly and with a system this complex the framework is no substitute for a clear definition of the goals of the system, how it has been implemented and how the data is organised – all of which seems to be missing.
Poor use of MVC (Model View Controller):
The purpose of an MVC framework is to separate the different major functions of the site so that it can be worked on by people with different skills and easily maintained on an ongoing basis.
The Model, which is the heart of data driven site, should contain the business logic, in particular the routines that access and update information or data.
The View should contain templates to display the site in different languages and for different devices like mobile phones.
The Controllers should identify which View a request needs and which Models it needs to access to provide the data for templates. All contemporary literature and generally accepted best practice (including Zend) recommends keeping the Controllers small and simple.
This site contains over 13,500 lines of code in the controllers, including one of the most important controllers, which has 3,000 lines of code on its own – this is anything but “Small and Simple”.
There is also far too much code in the Views, which do not use a dedicated templating language. There is even more code in the View helpers which also access the Models but do not show up in the Controllers.
This means that the organisation provided by the framework is almost completely subverted. The code starts to become one mass of up to forty thousand lines of interconnected spaghetti code, which probably explains why the system is so slow and makes it almost impossible to build a Version 2 of this system as it stands today.
The Controller should act as a manifest or list of which resources are required for a particular request or action. This means that when the site has performance issues, you should be able to quickly identify which resources are causing the problem. The complexity of the Controllers and the fact that some resource access goes through the helpers, not the Controllers, makes identifying performance issues very difficult and extremely time consuming and it make rectifying issues near to impossible.
Another good reason that the Controllers should be kept simple is that Models and Views can often be easily transferred from one framework to another (see next section), whereas the Controllers are more unique to a particular tool. Some frameworks use no code in their Controllers whatsoever.
The whole framework directory structure is also very complex, with no documentation or guidelines of why it has been implemented in this manner.
Choice of Framework:
It is debatable whether an MVC architecture is the ideal structure for a social media site. Because the site will contain content, which is defined by managers and ultimately end users, it is questionable whether the structure of the site should be driven by its directory structure, as opposed to being data driven. Again, this has performance implications.
Regardless, having chosen an MVC structure, it is difficult to see why Zend was used. It is one of the biggest and most complex frameworks and is widely regarded as one of the slowest performers, whether this site will scale to a million users is highly questionable.
Organisation and Management:
As above, a number of the fundamental design decisions were highly questionable, but the technical management of the site and development work is also flawed.
The source control system doesn’t work meaning that a number of people are directly using FTP (File Transfer Protocol) to update the main working copy of the site. This makes it almost impossible to test potential solutions. It also means that updating the site is complex with a good chance that one persons changes could overwrite, or otherwise compromise, somebody else’s.
There is no structured project management or work allocation/monitoring, other than a bug list with over a hundred items on it. Key members of the team are often too tired to produce high quality work or communicate effectively. Tasks are poorly defined and undocumented, which is confusing for the users, bad coding practice and will be very difficult to understand in six months time when something needs fixing and the developer that did has left.
There are no written guidelines on the configuration of the site. The site would not work with a standard installation of PHP because a depreciated (out of date) method was used to separate the PHP code from the HTML in the Views.
All of the above leads to very slow progress, poor morale and the application of unrealistic deadlines, which were never met, which is also going to impact relations with the client. Whilst this situation may be acceptable in the design phase, it should not exist in the development phase and is completely unacceptable and untenable once the site goes live.
It would be far more intuitive both for people using the site and for people maintaining it in the future, if content, such as polls, surveys, adverts, etc. could be added or maintained by editing a representation of the page itself.
Conclusion:
It is possible to rectify some of the more serious problems but it would be highly unlikely that such action and direction would come from the same people who created the existing system.
A large amount of the system could be migrated to a better design but it would have to happen very soon before the problems became entrenched and the system needed to be started from scratch.
The Bxxxx TV site is far too complex as outlined in the points below.
The purpose of this document to highlight some of the more serious problems with a view to providing guidance on the way forward.
Overall complexity:
Although the scope of this site is quite wide, it has been built in a way that makes the system difficult to maintain. Inormas are currently in the development phase, before people are using the site and it already slow and cumbersome - making changes will become much more difficult (if not impossible) once the site goes live.
The data structure is extremely (and unnecessarily) complex, the database contains over 100 distinct tables. By comparison, Facebook (built on the same basic code, happily supports 250 million users and all their content and applications with just 30 tables.
The system does not appear to have any design documentation or project plans and most of the code contains no comments (something that goes against all best practice). Although the system uses a framework, it uses it poorly and with a system this complex the framework is no substitute for a clear definition of the goals of the system, how it has been implemented and how the data is organised – all of which seems to be missing.
Poor use of MVC (Model View Controller):
The purpose of an MVC framework is to separate the different major functions of the site so that it can be worked on by people with different skills and easily maintained on an ongoing basis.
The Model, which is the heart of data driven site, should contain the business logic, in particular the routines that access and update information or data.
The View should contain templates to display the site in different languages and for different devices like mobile phones.
The Controllers should identify which View a request needs and which Models it needs to access to provide the data for templates. All contemporary literature and generally accepted best practice (including Zend) recommends keeping the Controllers small and simple.
This site contains over 13,500 lines of code in the controllers, including one of the most important controllers, which has 3,000 lines of code on its own – this is anything but “Small and Simple”.
There is also far too much code in the Views, which do not use a dedicated templating language. There is even more code in the View helpers which also access the Models but do not show up in the Controllers.
This means that the organisation provided by the framework is almost completely subverted. The code starts to become one mass of up to forty thousand lines of interconnected spaghetti code, which probably explains why the system is so slow and makes it almost impossible to build a Version 2 of this system as it stands today.
The Controller should act as a manifest or list of which resources are required for a particular request or action. This means that when the site has performance issues, you should be able to quickly identify which resources are causing the problem. The complexity of the Controllers and the fact that some resource access goes through the helpers, not the Controllers, makes identifying performance issues very difficult and extremely time consuming and it make rectifying issues near to impossible.
Another good reason that the Controllers should be kept simple is that Models and Views can often be easily transferred from one framework to another (see next section), whereas the Controllers are more unique to a particular tool. Some frameworks use no code in their Controllers whatsoever.
The whole framework directory structure is also very complex, with no documentation or guidelines of why it has been implemented in this manner.
Choice of Framework:
It is debatable whether an MVC architecture is the ideal structure for a social media site. Because the site will contain content, which is defined by managers and ultimately end users, it is questionable whether the structure of the site should be driven by its directory structure, as opposed to being data driven. Again, this has performance implications.
Regardless, having chosen an MVC structure, it is difficult to see why Zend was used. It is one of the biggest and most complex frameworks and is widely regarded as one of the slowest performers, whether this site will scale to a million users is highly questionable.
Organisation and Management:
As above, a number of the fundamental design decisions were highly questionable, but the technical management of the site and development work is also flawed.
The source control system doesn’t work meaning that a number of people are directly using FTP (File Transfer Protocol) to update the main working copy of the site. This makes it almost impossible to test potential solutions. It also means that updating the site is complex with a good chance that one persons changes could overwrite, or otherwise compromise, somebody else’s.
There is no structured project management or work allocation/monitoring, other than a bug list with over a hundred items on it. Key members of the team are often too tired to produce high quality work or communicate effectively. Tasks are poorly defined and undocumented, which is confusing for the users, bad coding practice and will be very difficult to understand in six months time when something needs fixing and the developer that did has left.
There are no written guidelines on the configuration of the site. The site would not work with a standard installation of PHP because a depreciated (out of date) method was used to separate the PHP code from the HTML in the Views.
All of the above leads to very slow progress, poor morale and the application of unrealistic deadlines, which were never met, which is also going to impact relations with the client. Whilst this situation may be acceptable in the design phase, it should not exist in the development phase and is completely unacceptable and untenable once the site goes live.
It would be far more intuitive both for people using the site and for people maintaining it in the future, if content, such as polls, surveys, adverts, etc. could be added or maintained by editing a representation of the page itself.
Conclusion:
It is possible to rectify some of the more serious problems but it would be highly unlikely that such action and direction would come from the same people who created the existing system.
A large amount of the system could be migrated to a better design but it would have to happen very soon before the problems became entrenched and the system needed to be started from scratch.
In other words, the current approach must be stopped and the solution migrated to a robust, reliable, scalable and properly built platform without delay because if this system goes live as it stands, it probably won’t work, it will consume vast amounts of time to keep it limping along and Inormas will lose credibility with the client to a degree which is probably unrecoverable.
So, the question is this: "Does this sound like the sort of project you would want to have spent a very significant amount of money on?" and, moreover, "Do these guys sound like they know what they are doing?"
"Cutting edge developers" that's pretty similar to how the people who built the Titanic would have described themselves at the time, doesn't it?
No comments:
Post a Comment