|
Best Practices != Innovative
!Innovation => Stagnation
Stagnation <=> death
Leave "best practices" to machine written code (and perhaps, textbooks)
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Best Practices are Not the stop of inovation, they can be the spur to it. Many times, I will write something "quick and dirty" to make sure my concept works, then I re-write, as many times as I need to, to make sure someone else, can add to or update my code as the need arises.
You want to be innovative, then figure out how to do it, then re-write to make it work with best practices. I would not mind hiring a "quick fix artist" IF, I could also see the cleaned up code.
"Dirty code" and "Quick Fix" MIGHT get you out of an issue, however if not cleaned up and made "Best Practice" i.e. clean code with explanations, you will not find others willing to work with you or support your efforts.
We have all add to through a "patch" into code to keep it running, (Even Microsoft) But don't plan on the patch to fix sloppy work. If you know it will be needed, do it now.
|
|
|
|
|
Doug- VisualBasic VB.NET wrote: you will not find others willing to work with you or support your efforts.
Quite a presumption on your part.
Reality: Others want to know "how did you do that ? !". Deliberately exaggerating, I look at so-called "best practices" as a combination of someone with influence trying to make me into a follower (of them) rather than a leader - and (other part of the combination) a fad for coding like the latest in overpriced fancy sneakers. One needs simply to be open to new methods to solve what (in reality) are old problems.
Real "best practices" is the most appropriate solution for a problem - in any field - crossing all boundaries. And - since I follow logic and efficiency I keep my audience attentive and appreciative with . . . . . . . extensibility* and comments.
Battles are not won by those who read the books - they're won by those who write them.
* as appropriate.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: Paraphrasing that wine commercial, "I will release no code before its time".
Sidetracking a little: We used to end the Saturday shopping round at our local microbrewery pub. Once when I ordered a glass of porter, the waitress checked her watch: I'm sorry, but the brewmaster will not release the new batch of porter until 3 o'clock...
|
|
|
|
|
... about how the coding is done (we could be monkeys at the keyboard) and in the end they pay for our living.
If the question was about the code then the answer would be it depends, some code needs to be perfect, some features being available faster at the expense of correctness is better.
Exception up = new Exception("Something is really wrong.");
throw up;
|
|
|
|
|
...but users do care if the app performs well, if it doesn't produce unexpected errors, doesn't crash, produce expected results overall and if it's pleasant to use, has good UI. And all of this can be part of doing it well.
|
|
|
|
|
So what you're saying is that the user experience is what matters most, but the business rules must be taken into account. And given that this is VERY subjective, can we really get by with just "getting it done"?
Thank You,
Andrew
Cobalt Software Systems, LLC
When Quality Counts...
|
|
|
|
|
In the real world, issues such as funding, timing (e.g. releasing a new game just before Christmas), etc. play a major part.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
The heart of a developer wants to do it "right"... perfect... in most cases.
Exceptions are when you get forced to write stuff you really hate... and you just want to get it off your desk.
But in normal circumstances, you want to get it done and you want it to be pretty... stable... and as-perfect-as-possible.
Many of todays paradigms try everything to work against this. scrum/agile tells you to deliver fast and refactor often. that's fine from a money-perspective. I personally love much of the agile things, but it more often than not hinders me to do things perfect.
sometimes it feels more like a prototype that will "get fixed later". as long as the story points are met, everything is fine.
Not.
To my luck I am part of a team that sees exceeding the estimated story points less a factor than delivering something that might not hold to the customer's expectations. But there are other companies out there that act blindly.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
