|
The thing is, if you are experienced, hopefully you can see where you can maybe skip a bit now but have no problems going back and updating those parts later, because they are well divided or layered. You can concentrate on the big picture, knowing that you are don't have the ultimate implementations of the bits that you are slotting into that architecture, but that (to the degree possible) the improvements can be internal to slotted in bits. Then you can attack the internals of those once it's all sort of fitted together and you can see how it works in the real world before you start getting precious about the details.
The same sort of strategies that allow for encapsulation and layering in the long term can also be put to use here. In some cases you can even have them just simulate what they will ultimately be doing and make sure the overall interface between the parts is going to be sufficient.
Explorans limites defectum
|
|
|
|
|
It's quicker in the long term: you get less bugs to track down, you have much easier mods to do when the spec changes (and it will, it will ...), and you get much, much cheaper maintenance when it does go wrong.
After a while, it works out pretty much as quick as the quick and dirty "who cares about quality?" method.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
...you get fewer bugs...
There are degrees of 'rightness'. One should have, at a minimum, a decently-tiered setup with separation of app/persistence/logic layers. A controller should not be opening a db context to persist data, for example (unlike the herp-a-derp idiots I work with); it should collect that information and pass it to a layer which specializes in persistance.
Most of us are also writing software for a business, so it's not purely an academic exercise. At some point, we need to deliver something.
Sometimes, we should present to the business people the options. For example, "If we reference an enumerated value to make this decision, and you want another value in the future, that's a code change. However, we could add an attribute to that data, and build an administrative function to make it totally flexible. That would take about X days."
The business can choose to go the quick-and-dirty route, or might foresee other uses for the new functionality, and want to turn it on and off. I'm pretty agnostic to their choice. As long as I recognize that, present them with options, and document their decision, I'm pretty o.k. with whatever the outcome is.
So I guess my synopsis is, I generally agree with Griff, if we understand that there is a business element.
|
|
|
|
|
This quote applies to many things in life, not just programming.
|
|
|
|
|
To quote Krusty the Clown... "It's not just good, it's good enough"
|
|
|
|
|
Paraphrasing that wine commercial, "I will release no code before its time".
Avoiding my normal verbose posts, it's as simple as once you establish a reputation for stable, solid, bug-free, maintainable and up-gradable software you can take your time to do it right and the management eventually figures out it's not only cheaper for them but, in real time, faster.
OK - I'll go verbose.
The time spent undoing bad data, alone, that may have gotten into the system from a flawed (rushed) release alone pays for itself many times over in time, money and avoided aggravation. I've had to train a few employers so that they get it that "I know what I'm doing".
Added bonus: when you tell them "no" on a feature or something of that nature they realize it's usually easier for you to do it than to argue - and listen respectfully why you think its a bad idea (with or without alternatives).
A reputation, (yours), is worth your term (and "theirs")
| 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 |
|
|
|
|
|
Completely agree, and I add the following advice for young and naive coders:
Just because you don't understand best practice doesn't mean there isn't a good reason for it.
If you disagree with best practice then in all probability you don't understand it.
Best practice is decided by well educated and experienced peers, that means they might know something that you don't. Something not obvious now that might come round later and bite you on the rear-end. Best practice is a standard, that means that if you are a "rebel" and don't follow it all you are doing is making it harder for someone else who has to debug your code later to work out what you were doing, or trying to do.
Now sometimes you really won't have time to do the job properly. You'll need to take the cheat's way out, make assumptions, second-guess what the user might do. BUT even then you should follow best practice as far as you are able. Keep the code clean and standardised: if your "cheat" works well done; if it crashes then you'll be glad you built in the error reporting and comments, you'll be delighted that your colleagues can spot your cheated section and help spot the missing comma or wrongly placed negative sign. Best practice is not an option, follow it.
|
|
|
|
|
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
