Page 3 of 3

Posted: Wed Sep 20, 2006 12:05 pm
by s.dot
Everah wrote:Well, I suppose I should claify that choosing to adopt a standard that is not exactly in line with the Best Practises of an industry does not in any way imply the use of worse standards. Who said that Best Practises are the best methods? Who said those methods will fit my business rules within the scope of my need for the technology in that industry?

What I am saying is that, while best practises exist, there needs to be some common sense applied to the adoption of those practises. Just because someone puts a list of ideals into a collection called best practises doesn't make them the best way. Moreso if you get more specific to an field within the industry. However, a standard can be developed that is visible, clearly spelled out and clearly agreed upon by those members utilizing that standard in a way that makes deviating from that standard as visible as the standard itself. This ensures consistency and the commonization of practises within your scope of work within your area of the industry in which you are a part.

I may not be stating my position correctly, but I am not advocating 'worse practises' by saying that best practises are not necessarily relevent to a particular segment of an industry.
With that speech alone... Everah for prez!

[edit] By time I read the entire topic there was already a whole nother page of replies and my post seems out of place. :oops: My motion still stands, though. Everah for prez!

Posted: Wed Sep 20, 2006 1:31 pm
by RobertGonzalez
+1 to that scottayy!

Re: Strong code vs working code

Posted: Thu Sep 21, 2006 12:50 am
by commoz
The Ninja Space Goat wrote:
onion2k wrote:
arborint wrote:Peer review, refactoring, and test driven development are the premier methologies today to do what you are looking for.
Note that very, very important word. Today. They're the latest fashion. They're not a wonderful code panacia that will answer all your development ills.

All object orientation, patterns, pair programming, tdd, etc actually do is formalise the way people develop software. If you've already got a system that works well for you then there's no compulsion to change, especially if that means you'll end up producing worse code. Software developers are notoriously disorganised and lazy (yes we are) .. all these fashions in development try to do is make sure everything actually gets done.

Also, there's a much larger proportion of people in the software industry who have learnt to program at university these days rather than being self-taught. Academia is always coming up with new and exciting things to teach people without actually understanding what goes on in the real world. Much as I'm loathe to say it, sometimes quick'n'dirty code is better. If you're working for a small company occasionally you'll need to consider things like cash flow when you're writing something .. sometimes you'll need to bang out some code as fast as possible just so you can get the invoice out .. if you insist on using TDD and refactoring in that sort of situation then you won't have a job any more because the company will have gone under.

The rule is really that you should write the code that best suits the job. If you have plenty of time, money in the bank, and a client that will be paying for you to maintain the code, then write the highest quality software you can. If you need the money now, or the code is just a one-off noone will ever visit again, <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> it, chuck out something that works and to hell with the standards. You've got to live in the real world.
A++ Great Advice Image

make that A+++
ImageImageImage

Not all employer's are the same. But one thing is same: THEY ARE THE BOSS.
We are paid to make the code working.
Most of the BOSSes don't hire us to make ELEGANT codes.
Generally they hire us because we can provide the services/job they need.
And the TOP Question that they always throw on us is: WHEN WILL YOU FINISH THE JOB?
Time is money. We work for money. Time and money is inversely proportional in business.
Too long to get the work done, they (BOSS) loose money.
Make quick solution, make fast money.
Anyway...change is inevitable.
If there's a bug, we fix it.
IMHO, As we aged in programming, we will end up as elegant programmers or quick fixers.

Posted: Thu Sep 21, 2006 1:33 am
by timvw
Very often i see people who say that if you look back at a program after a couple of months you'll usually find out what worked and what didn't work... The same remark is made when it comes down to peer reviews... Imho they are all about the same: experience as a programmer.

Write more applications -> develop more experience -> write better applications -> develop more experience -> ...

Reading other's code might work too, but for a beginning programmer it usually takes too much time to reverse engineer the application and get into the author's mindset...


If you want to write strong code you'll certainly need to write working code. If you have more experience, you can predict better how the requirements will change, and take that into account while you're attempting to write strong code.

Re: Strong code vs working code

Posted: Thu Sep 21, 2006 10:28 am
by RobertGonzalez
commoz wrote:Not all employer's are the same. But one thing is same: THEY ARE THE BOSS.
We are paid to make the code working.
Most of the BOSSes don't hire us to make ELEGANT codes.
Generally they hire us because we can provide the services/job they need.
And the TOP Question that they always throw on us is: WHEN WILL YOU FINISH THE JOB?
Time is money. We work for money. Time and money is inversely proportional in business.
Too long to get the work done, they (BOSS) loose money.
Make quick solution, make fast money.
Anyway...change is inevitable.
If there's a bug, we fix it.
IMHO, As we aged in programming, we will end up as elegant programmers or quick fixers.
You know, there are several folks trying to develop for my company right now. I was brought in to head up a project that is going to be a mission critical application to the company, and after that, clean up what is being done. These other developers threw things together that made their bosses eyes light up. And their code is riddled with security flaws, vulnerabilities, incorrect code and all sorts of problems. So I agree with the statements you make about time and money, but it is a little tough to agree with coding to get the job done. I am of the opinion that you chould cleanly and securely code to get the job done. Throwing some piecemeal junk together now that makes the screen look like what you want will invariably cost more money down the road either in redevelopment or court costs. Perhaps both.

Posted: Thu Sep 21, 2006 10:54 pm
by Christopher
I am bewildered that people actually believe things like that Best Practices are from academics, or that they are somehow time consuming wastes of time, or that they are just "elegant code", or that they take longer, or cost more? :(

Posted: Fri Sep 22, 2006 3:35 am
by onion2k
arborint wrote:I am bewildered that people actually believe things like that Best Practices are from academics, or that they are somehow time consuming wastes of time, or that they are just "elegant code", or that they take longer, or cost more? :(
You've misunderstood. Noone is saying that best practises are a waste of time. What people are saying is that whatever practises apply to your project is a matter of opinion. What's best practise for one project might not apply to another. It depends on the situation.

Posted: Fri Sep 22, 2006 4:16 am
by Maugrim_The_Reaper
They wouldn't be called best practise is they were any of the above...;).

Posted: Fri Sep 22, 2006 4:46 am
by Christopher
onion2k wrote:You've misunderstood. Noone is saying that best practises are a waste of time. What people are saying is that whatever practises apply to your project is a matter of opinion. What's best practise for one project might not apply to another. It depends on the situation.
That's my point. I think people think that Best Practices are "a matter of opinion" and not the collected knowledge from expert programmers. Nor are they overarching in that they would apply to a whole project in the way you mention.

Posted: Fri Sep 22, 2006 5:20 am
by onion2k
arborint wrote:I think people think that Best Practices are "a matter of opinion" and not the collected knowledge from expert programmers.
Expert programmers don't always agreement on what's best.

Posted: Fri Sep 22, 2006 11:10 am
by Christopher
onion2k wrote:Expert programmers don't always agreement on what's best.
I think they agree on 99% of best practices -- they just happen blog on the 1%.

Posted: Fri Sep 22, 2006 12:39 pm
by alex.barylski
^^^ I have to agree with onion2k here...

Anything as subjective as design patterns, TDD, Agile, XP, etc...there is always going to be argument and/or debate, even amongst those experts. ;)

My argument goes like this: Certainly these best practices are typically better approaches to what one may be doing currently, but they are by no means the best or only way of doing business.

Posted: Fri Sep 22, 2006 12:51 pm
by Christopher
Hockey wrote:Anything as subjective as design patterns, TDD, Agile, XP, etc...there is always going to be argument and/or debate, even amongst those experts. ;)
Only using patterns would be a best practice. TDD, Agile, XP are all metholologies that include best practices within them. Patterns are not subjective -- they are just not implementations -- that's not subjective. I just don't hear any experts say "don't use patterns at all, they are stupid and suck."

Posted: Fri Sep 22, 2006 1:00 pm
by alex.barylski
Thanks for making that distinction ;)

I'm too lazy to scroll up and down, but who said anything about being "stupid and they suck"??? :?

Posted: Fri Sep 22, 2006 1:39 pm
by Christopher
No one here said that. My point was just that I don't hear much disagreement among experts. I can't recall reading respected developers saying: don't use version control or forget patterns or create modules with lots of different responsiblities crammed into them. I don't think I even hear don't write unit tests -- the amount of coverage is the question.