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.
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!
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.
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")
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 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.
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.
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...
...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"?
Cobalt Software Systems, LLC
When Quality Counts...
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.
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.