January 10, 2006 at 11:46 am
Quality has always been a big topic for us. We've found an effective way to deal with quality issues in our T-SQl is through the use of several layers of code reviews. Obviously, as others have mentioned, it isn't the code review or the even the code itself that generally guarantees the quality. You do have to have a standard though. We follow a basic guideline of focusing on 1)security, 2)maintainability, 3)performance, 4)scalability.
Depending on the functionality, performance and maintainability may swap seats. If we absolutely need a page to load faster for a client implementation, a stored proc will be tuned for performance rather than ease of maintenance (example only).
Jay Holovacs makes a good point regarding metrics. What good is the metric if it only measures certain strict criteria and not the value of the whole? In the end, I feel that quality must be defined. There must be some standard by which everything is performed. At the same time, it must also be flexible enough to take into consideration that for instance, performance is not the end all be all of a T-SQL query.
January 11, 2006 at 7:11 am
Many of the points that have been discussed are valid, some are an attempt to herd cats! First, if you want to be a developer, get a degree in software engineering. It is a difficult degree, but you will learn the engineering principles needed to code with quality. Secondly, as Alexandros A Nipirakis said, a lot of development is ART! Art depends on your ability and intelligence to appreicate complex events. Most people look at something (art) and can only decide if they like it or not, which has nothing to do with the measure of artistic value. Get a grip!
January 11, 2006 at 9:22 am
If I may respectfully disagree with nunYoBusiness...I've found that degrees are a useless indicator of developer capability. I've found that typical engineering principles are only useful with embedded development, writing drivers, that kind of thing. I.e., programming for machines. When programming for people, I find that engineering principles are counterproductive.
January 11, 2006 at 3:24 pm
February 1, 2006 at 12:06 pm
Frank Buchan and David Reed both make the point about weaknesses in business analysis contributing to poor code quality.
Quality is something that needs to be something applied to throughout a business not just in isolation within one department.
Improve the BA you improve the tech spec, improve the tech spec the developers and testers get a clearer idea of what is required, improve the testing and fewer bugs make it through to production and this leads to improved customer satisfaction.
You can only achieve so much improvement working in isolation.
Aleksei brought up the point of being the sole developer or SQL guy. If you are the sole guy then you are going to have the big picture on a project rather than small pieces so of course it is easier to produce quality code.
Developing within a team environment is like stepping up from being a good club athlete to competing on the international stage. Again, you can only achieve so much working in isolation. It takes tremendous self discipline to maintain a quality standard when the pressure is on and there is no-one to police your quality. This leads on to Alex's comments on code review. This can be painful and very sobering but I feel that this is a very important part of any development cycle.
Just about everyone brought up consistency. Adopt a company standard and stick with it. Such a standard should be a skeleton and not a straight-jacket. Indoctrinate new employees with the company standard and ENFORCE it.
One thing one of my developers mentioned (which was blindingly obvious AFTER he said it) was make sure that all parameter names are consistent throughtout all stored procedures.
Don't have AccountID, Account_ID, accountId and obviously don't start calling accountid customer account.
Use
select distinct parameter_name,data_type,character_maximum_length from information_schema.parameters order by parameter_name
and the information_schema.columns equivalent.
Get a good documentation tool such as ApexSQL Doc or Innovasys DocumentX (neither is expensive) and comment your database to make use of these tools.
Make use of the templates in SQL Query Analyser. Its free with SQL so use it. Write your own to the house style.
Use SourceSafe or similar product.
Write your code as if you were instructing a junior programmer. They might learn something and you won't get chained to your old achievements.
Timeliness raised its head in this thread.
Writing quality code may take time but it is easier to debug, performance tune and extend. Yes you can throw stuff out of the door for the client but if you do work with external clients what you want is customer retention because it is the 2nd and subsequent projects where the big money is made.
Timeliness improves with an end-to-end quality improvement.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply