Development Standards are an important aspect of software development. Whether you are a one man band developing a small product for sale over the internet or part of a multi-national multi-disciplined software development team, getting them right for your environment has a significant impact on your ability to grow and maintain your application.
Development Standards are all about best practices. This can be anything from a consistent screen design and menu layout right through to creating performance tuned code. Of course, in between there is a whole plethora of other important areas like architecture, naming conventions for your objects (tables, fields, programs etc), program layout, parameter interfaces, component selection and code comments to name a few.
A full list would be almost infinite and depends on the type of application, number of developers, platform, language choice etc as to what and how you implement a standards strategy. However, not having a development standards strategy is guaranteed ‘Developer Armageddon’ some time down the line.
Put simply, 90% of a software applications life is spent in maintenance mode. Not very nice but this is a simple truth of application development. Given this statement, it still amuses me that many software developers naively ignore development standards and certainly the importance of them during initial design and coding stages of a products evolution. I guess coding standards at that ‘Green Field’ stage of a project are not sexy, yet, this is probably the time when you have your best chance to positively affect the longevity of your creation.
I have witnessed development teams rush merrily down a rewrite in the newer technology/language/platform, only to rewrite the framework a release or two later.
This happens for two reasons, commercial pressures and time to market, but mainly through developer’s misguided curiosity and priorities. The developer is so eager to please their boss and desperate to use the new technology they naturally enter the feature race. A feature race is when a developer spends more time creating widgets and impact items for your application rather than design a sound framework.
Of all projects that I have worked on, the most successful are those that have been carefully thought out. A framework had been chosen/written, design patterns devised and standards implemented before the first line of production code had even been written.
Production code is quite an important term in this whole discussion. Too many shops go from prototype to production by renaming the application. People should be aware that the reason why car manufacturers make a prototype car out of clay is to ensure that it will look good and get early feedback. You don’t see Ford then add a couple of wheels and drive it away. Yet, time after time after time, this is how software projects start.
These are the projects that will hit framework 3.0, rewrite 2.3 and expiry 4.5.
So what are standards?
Effectively they are a collection of common points. They describe a common language, common style, common platform and environment techniques, common application attributes. Once everybody is doing their development in a consistent manner you have unlocked the door to a productive development environment, and that makes common sense.
So why do we need standards?
Most applications start off simple but over the years they invariably get more sophisticated and therefore difficult to maintain and grow. When you are dealing with thousands of programs and millions of lines of code it is quite obvious that having carefully applied standards would be more beneficial for software maintenance. Also that tight small development team that started the application development way back when is unlikely to still be the team developing/maintaining the application many years later. Therefore, these standards will serve the test of time and allow your application and organisation to change as these things do.
However, putting a standards strategy in place is one thing. As much as change is guaranteed your standards also have to evolve. Many are key development principles which apply to any situation and every developer, others need to be tweaked as things change whether that is new technology e.g. XML or identifying a better leaner way to perform an old standard. Be prepared to review your standards periodically and work extra hard to ensure that they are being implemented.
Ultimately the key issue about standards is the ‘buy in’.
It is absolutely pointless in agreeing a standard and then ignoring them. The best way to get developer ‘buy in’ is to involve your developers in the process. Ownership of standards is easy, they are owned by all interested stakeholders. This is from the Managing Director down.
So the standards are ‘ours’, the companies, they are a collection of guidelines to assist us in creating our application.
Strong standards and consistent implementation of the standards will improve our product, our productivity and our individual technical ability.
Development Standards are all about best practices. This can be anything from a consistent screen design and menu layout right through to creating performance tuned code. Of course, in between there is a whole plethora of other important areas like architecture, naming conventions for your objects (tables, fields, programs etc), program layout, parameter interfaces, component selection and code comments to name a few.
A full list would be almost infinite and depends on the type of application, number of developers, platform, language choice etc as to what and how you implement a standards strategy. However, not having a development standards strategy is guaranteed ‘Developer Armageddon’ some time down the line.
Put simply, 90% of a software applications life is spent in maintenance mode. Not very nice but this is a simple truth of application development. Given this statement, it still amuses me that many software developers naively ignore development standards and certainly the importance of them during initial design and coding stages of a products evolution. I guess coding standards at that ‘Green Field’ stage of a project are not sexy, yet, this is probably the time when you have your best chance to positively affect the longevity of your creation.
I have witnessed development teams rush merrily down a rewrite in the newer technology/language/platform, only to rewrite the framework a release or two later.
This happens for two reasons, commercial pressures and time to market, but mainly through developer’s misguided curiosity and priorities. The developer is so eager to please their boss and desperate to use the new technology they naturally enter the feature race. A feature race is when a developer spends more time creating widgets and impact items for your application rather than design a sound framework.
Of all projects that I have worked on, the most successful are those that have been carefully thought out. A framework had been chosen/written, design patterns devised and standards implemented before the first line of production code had even been written.
Production code is quite an important term in this whole discussion. Too many shops go from prototype to production by renaming the application. People should be aware that the reason why car manufacturers make a prototype car out of clay is to ensure that it will look good and get early feedback. You don’t see Ford then add a couple of wheels and drive it away. Yet, time after time after time, this is how software projects start.
These are the projects that will hit framework 3.0, rewrite 2.3 and expiry 4.5.
So what are standards?
Effectively they are a collection of common points. They describe a common language, common style, common platform and environment techniques, common application attributes. Once everybody is doing their development in a consistent manner you have unlocked the door to a productive development environment, and that makes common sense.
So why do we need standards?
Most applications start off simple but over the years they invariably get more sophisticated and therefore difficult to maintain and grow. When you are dealing with thousands of programs and millions of lines of code it is quite obvious that having carefully applied standards would be more beneficial for software maintenance. Also that tight small development team that started the application development way back when is unlikely to still be the team developing/maintaining the application many years later. Therefore, these standards will serve the test of time and allow your application and organisation to change as these things do.
However, putting a standards strategy in place is one thing. As much as change is guaranteed your standards also have to evolve. Many are key development principles which apply to any situation and every developer, others need to be tweaked as things change whether that is new technology e.g. XML or identifying a better leaner way to perform an old standard. Be prepared to review your standards periodically and work extra hard to ensure that they are being implemented.
Ultimately the key issue about standards is the ‘buy in’.
It is absolutely pointless in agreeing a standard and then ignoring them. The best way to get developer ‘buy in’ is to involve your developers in the process. Ownership of standards is easy, they are owned by all interested stakeholders. This is from the Managing Director down.
So the standards are ‘ours’, the companies, they are a collection of guidelines to assist us in creating our application.
Strong standards and consistent implementation of the standards will improve our product, our productivity and our individual technical ability.
Thanks for reading.
Lee.
No comments:
Post a Comment
Thanks for considering leaving some comments about my random rants for everything software development and more.