May 15, 2008 at 8:28 pm
Comments posted to this topic are about the item A Worthwhile Goal
May 15, 2008 at 10:53 pm
Nice one. Quality and consistency are based on time period of works.That is I had learned from you.
Regards,
Kannan
May 16, 2008 at 1:11 am
Consistency and readability.
I had the "pleasure" to hand over 3 years of development work and it helped that at the time of development I left enough comments in the code to understand years later what I intended to do. Some of the coding with hindsight might have been faster to accomplish with a more difficult to read construct but again with hindsight it was easier to pick up again.
Then right now I am in a code heap documentation from someone else. While consistent the readability leaves much to ask for. It looks like the code was written on a screen 50" wide and 5 " high. Very compact to the point where it is a block with no real visible structure. Sure, the Select and From and Where parts are segregated but that's about it.
Following the code is demanding.
Reworking this code in something into easier to read takes four developers quite a bit of time (the whole project lasts 6 years so far) and one in particular while insisting he thinks about the next developer doesn't seem to grasp the concept of easy to read code (and documentation, comments are used sparingly so as not to confuse between code and comments).
Consistency is starting to appear.
In a former job I numbered all DTS tasks plain visible in the design. Each task had a three letter shortcode for what type it is (although visible by the icon), its number and a short description what it is doing.
It saved me lots of time in debugging as I didn't need to go into the extended properties of a task.
This is just an example of what I think is important: Consistency is good, easy readability of code is even more important.
May 16, 2008 at 1:33 am
Interresting topic, but I sort of feel that the most important part has been left out, or rather not the most important part of this very topic but the reason we are talking about it.
Many companies starts up and has to do a lot of work and that fast to start generating cash, there for quality of the code is not their primary consern, the primary consern is to get a lot of stuff working decent so the company makes cash. This is often the reason I find that we end up in situations where we have a system or a part of a system that should have been designed in a nother way to be way better if the peeps creating it would have hade the time to think it throu.
May 16, 2008 at 2:40 am
Code standards can be the hardest to implement. Naming conventions are preferable, though keep it simple - just use prefixes.
The most important thing I have found is synchronising backups of development and test databases in time with release versions and maintaining a repository of them.
May 16, 2008 at 3:34 am
Consistency breeds quality. Consistency IS quality. You don't get quality without consistency.
You can have 3 incredibly bright developers but if they aren't adhering to some simple, documented, consistent standards then the thing that they build will be of poor quality.
Simple as that.
-Jamie
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson
May 16, 2008 at 5:31 am
I think getting consistency should be the first goal, then as you state you can start teaching how to write better code. IMO, there is nothing worse than going into someone else's code when there are not standards in place. Simple things like naming conventions, indentation, and commenting need to be consistent so you aren't searching for things.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
May 16, 2008 at 5:53 am
I'd follow a bit on what Jamie said: consistency tends to breed quality.
And, as IceDread noted, we need to factor in the time dimension; one can have both consistency and quality given the appropriate amount of time. However, in this age of highly iterative development lifecycles, we often set out establish standards and policies along the way, rather than at the outset, if they are not already in place. Obviously, one should implement best practices from the get-go, but consistency can be initially deprecated when release cycles are very short and simply made a part of the iterative process; iteratively build in consistency over time.
Where I am a data architect, at a large bank, I've had to build in the idea of establishing consistency over time because of time constraints (for whatever reason, management around here think you can build a data warehouse without a planning or analysis period). They just wanted it built and delivered. Typical 😉
The trick, of course, is to turn speed into scalability (consistency) over time. This approach has worked for us very well.
---------------------------
|Ted Pin >>
May 16, 2008 at 6:20 am
If I have to pick only one, I'd go with consistency. Once everything looks and acts similarly (even if poorly), it's much easier to work on the quality and raise the bar. However, both are an uphill struggle. I wish I had a dollar for every time I've heard "We're not building Amazon/Google" after suggesting changes from a code review or database test. But if you push the changes through, everyone benefits down the road. But for some reason, lots of developers only think about stuff to the point of rolling it out to production. They don't think about the long term maintenance, scalability, updates, changes, etc., that occur over the years.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 16, 2008 at 6:24 am
I would agree with the people who suggest that it's not one or the other. Quality code is code that can be built upon by someone other than the original developer. That means it is structured, consisten, and commented in a way to make it readable.
Unfortunately, the modern way that we start companies works agains foundations being laid in good code, whether measured by performance or scalability. Most businesses start with a few people who have a vision for a product. They're rarely "computer people". They keep records on paper or maybe a product like Excel. When it comes time for more computerized operations, they do what they can by themselves. By the time they get around to IT staff, the system is already in bad shape. To compound things, such businesses don't want to lay out a lot of money for IT, which they consider to be necesary evil. Good IT people cost money, so the more usual approach it to look around the warehouse and see if anyone wants to take an "intro to programming" course at the local community college or to hire somebody's nephew who likes to tinker with computers. It's rare (in fact maybe it never happens) that a disciplined approach to software is even considered until lots of code is written.
Oh, well. Enough of a rant. Assuming that you could separate the two, I would value consistent, readable code over hastily written but "fast" code. Unfortunately, business people are often looking for a quick bang for their bucks, so quickly written code that "gets the job done fast" usually wins.
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
May 16, 2008 at 6:45 am
Well if I walked into a situation I'd need to get a handle on it pretty fast, and if the code wasn't consistent then that'd take more time.
As far as quality is concerned, I'd be happy to walk into a situation with poor quality code, it would give me plenty of opportunities for quick wins....
May 16, 2008 at 6:50 am
Consistency. 100%. You'll need high quality code to bridge the massive gaps that will develop in time if everyone is working independently.
So saying, I'd love to hear, from Steve Jones, what he does to implement consistency, as this is something I really struggle with in my job. Any advice on this would be appreciated.
Cheers,
Dave
May 16, 2008 at 6:54 am
As a contractor, I get to play in a lot of other people's code and it is different from one job to the next, and believe me, I see really well written code, and really poor code as well.
One thing I strive for is consistency with the established base of code because I want the changes or additions to have the same look and feel so that future developers don't have to figure out multiple coding styles. This usually applies to things like naming conventions, layout, and more esoteric things.
I do draw the line when it comes to good coding practices. For example, if previously they used looping code (cursors, while loops, etc) to do things where set-based code could have been used, I won't continue that practice in any new work, if it can be avoided.
Also, I have seen variable naming conventions where they used letters of the alphabet which have no meaning as to the nature of the variable (a=1, b='cat', c='04/21/2005'). I won't continue to use that in new programming. Things like that make it really difficult to trace code and understand what is going on.
By no means will I go back to re-code things I don't think are proper or necessary (like the above examples) unless it is in my scope to do so (I was asked to change it) or it is affecting the changes I'm making. To redo someone else's code simply because you think your coding style is better (usually subjective) is arrogant at best, and can sometimes cause new problems if you didn't 100% understand what the code was doing. If the code is functioning properly and not causing performance problems (or won't cause potential problems in the future), etc., leave it alone.
So I think you have to have consistency, where it makes sense to have it, and you have to have quality to the point where the code does what it required to do, and meets or exceeds performance requirements.
If it was easy, everybody would be doing it!;)
May 16, 2008 at 7:07 am
The biggest thing is not to break the application(s).
There are retrofits to fix violations of first normal form (yes, comma-delimitted lists in a single field) that I've allowed to wait for years because of the pain of migrating the customers' data to a more reasonable schema.
New schema elements should be designed or at least approved by someone who understands DB design. That's usually not the sales/marketing team who just sold a new feature to somebody based on the idea that "we could just add 9 more fields in this table".
For new code I work to educate the other developers and raise the bar. As someone else said, quality breeds consistency.
May 16, 2008 at 7:11 am
Generally I agree with the other responses I've seen here. However, I think one crucial element has been overlooked. I've been a developer for only a couple years, so I might be closer to this than most of the veterans: "poor quality code" doesn't necessarily work.
I'm big on consistency and try to guide the other people I work with when it comes to naming conventions and such, but if quality is below the threshhold of accurate functioning, consistency becomes irrelevant.
Quality needs to be the first objective. How much easier is it to go through some code and fix prefixes, as opposed to re-writing one process after another because it's too big/too slow/doesn't work?
Viewing 15 posts - 1 through 15 (of 75 total)
You must be logged in to reply to this topic. Login to reply