May 16, 2008 at 7:18 am
Quality and consistency for me today!. I recently started a new job. My old company, everything was new and was built quickly but consistently (not always quality) so anyone could look at someone else's code and in a short period of time, fix whatever the issue may be. I got real comfortable and maybe a bit complacent as this was all I knew. After 8+ years, I moved on to where I'm at now. So many people over the time have created/bandaged systems here which makes it difficult to respond quickly to issues but also quite challenging (refreshing, if you will!). As Richard stated, "it gives me the opportunity for some quick wins". As we are looking at re-writing the systems in the near future, I am documenting what is currently in place and have tons of ideas for improvements - from normalizing the DBs, to more consistent code, to naming conventions, to better business practices - but it will be a team venture. That will make me look like a star. Am I? Not at all, but seeing both sides and what was easier from a maintenance/enhancement persepective, I know what I want. Will I get it? Not necessarily but by proving to management what is the best approach for them, and my staff, in mid-to-long term situations, they'll be hard-pressed to disagree. The company has been growing by leaps and bounds, but with good design, good quality and consistent practices, we can stay ahead of, or at least even with, business (and luckily, we'll be afforded the time to do this). I've learned a lot from my experiences, and forums like these, to know good from bad. That's why I keep coming back, you never know what additional tips you'll pick up. Thanks Steve for giving us a great place to exchange thoughts and ideas! It makes my job that much easier.
-- You can't be late until you show up.
May 16, 2008 at 7:22 am
Consistency will ultimately raise the quality of the work being performed, in all cases. Time to complete a project is also critical. Too many projects are put on short deadlines creating the perceived need to "just get it done." The problem is that you lose consistency and quality and then someone has to come back later and clean it up. I abide by the following question:
Why is there never enough time to do it right but always enough time to do it over?
May 16, 2008 at 7:27 am
If it's not too tangential, I'd notch my answer just a bit deeper and say that being data-centric is most important. By example, the business I work for started by seeing a database as a dumping ground for the application data. Six years later, and a much bigger organization with much, much more data, and the view is still largely the same. So structural database changes (quality improvements) can't occur because too much data management is handled at the application layer, and the lack of any data stewardship means at best some semantic consistency in naming database object naming conventions (consistency). Yet now the application is handling data management at roughly a zillion points so consistency cannot be handled there.
So I'd say consistency, driven by having a data-centric view of application development.
2 cents, after adjusting for inflation.
May 16, 2008 at 7:34 am
>>that being data-centric is most important
I used to agree with that. I've seen so many bad DB models driven by good UI layout only to have the nice layout crumble when the bad DB under it crumbled.
So I started designing my UI's based on a good DB structure. Users hated it.
Now I work from both ends toward the middle. I need a good UI. I need a good DB schema. The business objects in the middle need to do that transformation.
May 16, 2008 at 7:36 am
I, too, believe consistency breeds quality. And we use jim.powers phrase where I work, a lot! (meaning too much :hehe: )
A number of my personal peeves and best practices have already been mentioned, so I'll just re-inforce that consistent documentation in the form of short notes in the code has a huge impact on the programmer that follows you - especially if that programmer is you six months or more later! 😛
Steph Brown
May 16, 2008 at 7:38 am
In my opinion, there is a continuum. The larger a project and its development team is, the more important consistency becomes. At one former position, it was my responsibility as a team lead to enforce coding standards and conduct code reviews. I had some incredibly talented coworkers, and quality was high from the start, but at the outset, no one wanted to follow the standards. Truth be told, I didn't agree with some of them either, but as my project manager so eloquently put it, it was his job to make the rules, and mine to enforce them. Eventually we all got on the same page, and created a decent system.
At my current position, I have been incredibly fortunate. This time I got to be part of the team who designed the architecture from the ground up, with no constraints or legacy code to deal with. My program director is a former mainframe programmer who still very much remembers his roots, and gave almost full autonomy to the team, trusting that he had chosen wisely when he hired us.
May 16, 2008 at 7:40 am
I have been in my current job for about six months and have been struggling with these very issues. I think both are important, but am not sure one breeds the other. The code I have been dealing with is pretty consistent, however, the quality is questionable at times.
It turns out, I focused on quality first, then just recently turned to being more consistent. Much of the code is written from the developers native code standards and not to more "traditional" T-SQL standards, so it's difficult to get people to change. The challenge is trying to find a common ground. Developers seem to be more open to quality improvement than changing old habits.
May 16, 2008 at 7:44 am
If you have quality you can get some consistency with it. I have been on projects where the code was very consistent, but unfortunately it was consistently bad code. I will take quality code, which includes easy to read code.
May 16, 2008 at 7:44 am
I couldn't disagree more with the thought that consistency creates quality. In fact, I suspect quality creates consistency, because when most people find something that both works well and is comprehensible enough for them to follow, they'll use it.
And apparently Warren Buffet agrees. (I found it on the internet; it must be true.)
I finally remembered some useful advice I once got from a golf pro (who, like all pros who have had anything to do with my game, wishes to remain anonymous). Said the pro: "Practice doesn't make perfect; practice makes permanent."
As a long-time practitioner of structured programming, I still remember what one of my professors taught us:
It's easier to make a structured program work than a working program structured.
Mattie
May 16, 2008 at 7:47 am
I vote for consistency as I have seen its importance in my projects. I worked in a company where the resources are keep changing. In such cases, even if the developer is a brilliant guy, we cant depend on him unless we have a process to know what he is doing.:)
May 16, 2008 at 7:56 am
I think consistency is the place to start, but I do not agree that it will necessarily lead to improved quality code. However, consistency does provide a framework that can make it easier to identify poor quality code if people are looking out for it. Implementing a regular code review process by an administrator, manager, or senior developer (as applicable in your organization) can be a great opportunity to make improvements on both fronts.
We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true. -- Robert Wilensky
May 16, 2008 at 7:57 am
I'm going to vote for quality first.
Consistency is a form of quality. If a convention or practice is good enough to be enforced consistently, then it must be a quality practice, even if it's not the highest ideal.
I've dealt with a lot of code written by others. Sometimes the code is of adequate quality, just not quite what I would have done, and I can work with it. But, too often, the code is garbage. Harsh, but it's true. The users have been avoiding features that they know don't work and using work-arounds for bugs, and typically management doesn't even know. When RI is poorly implemented, I find garbage data, duplicates, missing data, you name it. In client code, there's often no way to continue working with a system that keeps all its data in global variables and has all its functionality in the GUI event handlers.
I'm a proponent of the complete re-write in these cases. A high-quality programmer can re-write code much faster than it would take to write a totally new system because the requirements are in the existing code (though it's sometimes a bit of a puzzle to figure them out). For garbage code, the re-write is faster than trying to fix it! The result may not be perfect, but it is maintainable, reliable, and incorporates any lessons learned from the design of the original.
Arrogant? Yes, I'll admit to that. But I've done it, professionally, many times and my customers are happy with the results.
May 16, 2008 at 8:03 am
Quality or consistency? OK, we know it's not an either/or proposition (focus only on improving quality and you'll never get anything done, focus only on consistency and you'll eventually find yourself technically obsolete and unemployable). But forced to choose, I pick consistency first when I start a new job or take on additional responsibilities.
Just recently, I took on the responsibility for a number of new SQL Servers (new to me at least). This process was hastened by the sudden departure of the existing DBA. While I was able to meet with him briefly before he left, I in no way gained enough knowledge to adequately support these systems right away (no fault of his, it just takes time). Upon performing my own audit of these servers, I saw they had some major issues to remedy: databases that had never been backed up, jobs failing, weak passwords, etc... In short, there were more than enough worthwhile areas to spend time on. For me, the goal was to minimize risk - this meant balancing making improvements (quality), while at the same time not breaking things too much (consistency). I needed to understand the databases first before making any changes.
For me, quality should be re-evaluated periodically, something more than a month, less than a year. When I think of quality, I think of major changes to how things are done. Improving quality takes a lot of time and effort. It's kind of like taking one step back in order to go three steps forward...
May 16, 2008 at 8:05 am
I guess it depends on how you define "quality".
From the business point of view, I'd rather have code with a solid ROI than "consistent", "standard", "well layed out" code that doesn't do what it's supposed to or does it very poorly.
Despite what some have said here, I've seen highly consistent, well-documented, easy-to-read code, that just plain doesn't get the job done, or does it so poorly it's useless. One of the worst code solutions I've ever seen was a hierarchy resolution that used 3 procs, 2 UDFs (one of which was recursive), multiple nested cursors, several temp tables (with no indexes or primary keys, of course). It was well documented, nicely laid out, highly readable, and followed all of the company's rules for naming conventions, et al. It also started timing out less than a week after it went into production. I replaced the whole thing with a single function with a single recursive CTE, and it's been running beautifully ever since. But one of the developers here says he gets a headache whenever he tries to read any of my code, because I don't lay it out the way he wants it.
Like everyone, I'd rather have both quality and consistency, of course. But if I really do have to choose between the two, I'll take quality. No hesitation, no equivocation, no regrets, definitely quality.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 16, 2008 at 8:15 am
I don't see how you can have real Quality on a group project without consistency first. Even if you manage to get a good product/project up and running without that consistency; you will not keep that quality overtime because you did not have consistency (almost equals discipline) in the first place. The hardest thing to do is come in after the fact and try and apply good practices to a inconsistent system. Never mind the enviable that really gets you - applying changes over time to an inconsistent system. "VIVA LA CONSISTENCY" (If you are French, forgive me.)
Viewing 15 posts - 16 through 30 (of 75 total)
You must be logged in to reply to this topic. Login to reply