The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Why does that upset you so much? Tell me how disliking a clumsy greedy company constitutes trollin you? Is Mickeysoft your name? Or your religion?
No, my friend, if anyone here is a troll, then it's you. You provoke, if that does not work you start calling names and if that still does not work, well let's try to turn the tables and accuse everyone else to be a troll.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
Okay okay okay
Just a little pinprick
There'll be no more, ahhhhhhh
But you may feel a little sick...
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
Some questions inspired by the earlier "I hate debugging" thread:
Supposing there was a scale from 1 to 10 which ran roughly as follows:
1) Get the damned job done anyway you can. Best practices? Never heard of 'em!
2) Quick and dirty's always done it for me, I try to be as tidy as I can be but I'm not going to fuss about high faluting concepts when my customer just needs a website.
3) I'll brush it up a bit when I'm finished.
4) I try to stick to some kind of decent design pattern but I'm not going to lose any sleep if I violate it here and there.
5) As long as things are done reasonably, that's cool. Yeah, I break a few rules here and there but hey y'know, you've got to be pragmatic.
6) I spend time upfront on design because good design leads to good code but I'm not going to get too obsessed with what the rest of the world does or doesn't deem to be best practice this week.
7) Best practices are worth aspiring to. I don't always use them but I do try hard to stick to the main ones.
8) Rules aren't carved in stone but there needs to be a damned good justification for deviation.
9) OMG! That line isn't covered by a unit test - that makes it LEGACY CODE! And look at that! A singleton! It's a goddamn anti-pattern! I don't feel too well ..
10) The Law of Demeter has been broken and the crops will fail if I don't rewrite the whole damned thing from scratch.
Now, obviously this is a rather arbitrary (and slightly flippant) scale but assuming a general spectrum running from Q&D via pragmatism to extreme perfectionism:
a) Where would you place yourself on the spectrum?
b) Where do you think that you should be on the spectrum?
c) What do you think are acceptable points on the spectrum for others to occupy?
d) Does your position vary according to what you're working on (e.g. is your attitude to a web-site different to your attitude to designing a database? If you write both low and high level code, does your approach change?)
a) Between 7 & 8, probably.
b) Between 7 & 8, probably.
c) Between 0 & 11, probably.
d) No, not really - my personal feeling is "if a job's worth doing, it's worth doing properly". I do not like doing the same tasks repeatedly (one of the -many - reasons I hate mowing the lawn). High and low level aren't as different as you might think, it's just a different environment in which to work - there is a smaller difference between embedded code and a Windows Forms app, than between a Windows Forms app and a website for example.
I try really, really hard not to have to revisit code, but I make it as easy for myself as a can, because I know there will be bugs, will be changes. Doing the right thing now saves me a lot of effort later when I've forgotten why I did something "clever".
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
c) It would vary between different projects and teams. Somewhere in the middle would be good to aim for.
d) Yes. The bigger the code and the more people that would need to maintain the code, the higher up on the scale the project should be. If the code needs to be certified the number should be higher than if the code is to be used by one or two people occasionally. Good design is always a good idea and I wouldn't go below a 4 on the scale. I've seen code where developers add complexities and convolutions just to make the so-called best practice 'work'.
usually working on back room [db] apps, about 8, with justifications:
1. solution must fit business requirements - never visa versa
2. even more must [and as efficiently as possible] fit the physical work flow.
small to medium sized businesses have often developed their own in-house work efficiencies that for capture and reporting don't always fit well with [mostly database] best practices.
(So the question is: the "best practices" are for who? - for mine many are really only "best" for keeping newbies in line until they learn how to fly.)
I think the main two categories for answering this are:
1. sole programmer at company who will never really be replaced.
2. programmer is a part of a team
For 1 - I don't care what the code of the sole programmer looks like. It's his own foot he'll shoot off later anyways. Just make the doggone thing work! In every way, performance, security, everything. I don't want to see your code. I don't even want to smell your code, no matter how stinky it is. But you better be able to fix it fast when it breaks in production or when there is a new Windows API and it breaks or whatever. Fix it and no whining.
For 2 - If i'm going to look at your code and you're going to expect me to do something with it, make it clean. Use patterns, use great variable names, use true OOP and SOLID principles.
And, if I come to you and say, "Hey I need to convert HTML to PDF and you've already done that in the Chupacabra software, right? Can I just get that method from you?" then you better be able to say, "sure, it's in a library just add it in and call ConvertHTMLToPDF(htmlFile) and you are done.*"
And, right, I don't care about rules** even if they're named best practices. However, I do actually care about best practices and code conventions that make my life better. Plus, if you are following what I said in 1 or 2 above then all is good and easy anyways, because it is right.
*That's a true story where I went to someone who had that, but the code was inside his WinForm class. Couldn't be used. Ugh!
Hell there are no rules here. We're trying to do something.
d) Usually I couldn't care less about some interface implementation as long as the overall design is good.
So for the architecture I'm probably a 7 or 8, while for the implementation I'm leaning more towards 3 or 4 or even 2. The implementation should be easy to fix anyway, while the architecture isn't!
Too bad I often find some disposable code all polished up and unit tested while the architecture looks like spaghetti
1-3: Experimentation code, usually when I'm learning something new or putting together a proof of concept. Once I have a handle on the tech, I move the code into the next category.
4-6: This where the balance between "how much effort do I put into this?" and "oh yeah, the client is paying me hourly for this code?" starts to take effect. There's also the temporal effect, being that my code stays in the 4-6 space for various time intervals, from very short (minutes) to very long (months), depending on how entangled it starts to get with other code. Some stuff is just a one-off utility, other stuff gets merged in with the rest of the code base and needs cleaning up at that point.
The 4-6 space is also where I live when I've attained some knowledge of the technologies and requirements, but certainly not mastery. (Mastery of requirements usually occurs over time as the client/customer provides more detailed feedback.)
7-8: Ultimately, my code tends to end up in this space, but my concept of best practices are rather different than "industry standards," or so I imagine, since I really have no idea what "best practices" means since it seems to be such a moving target. So I've evolved my own. At this point, in order to get into the 7-8 space, I must also have achieved mastery over the tech, the requirements, etc. This is where long term projects live, and they live because they are maintainable and easily enhanced.
9 - line by conditional line of unit testing, anti-patterns, and whatever else fits in the religious zealotry of the best practices category is a red flag to step back into the 7-8 space.
10 - Yeah, there's often a jump from the 4-6 space to the 10 space to get to the 7-8 space. The pain of learning how to things right.
As for c), I'd say at least the 4-6 space, and if you think you're code lives in the 7-8 space, you'll have to answer to me, mwahaha.
b) would depend on the context, and the current project
c) would depend on the context, and the current project
I do think that the larger the team size, and the more complex the project, the more formal development methods, and stronger management, are required
from the sidelines, Bill
«When I consider my brief span of life, swallowed up in an eternity before and after, the little space I fill, and even can see, engulfed in the infinite immensity of spaces of which I am ignorant, and which know me not, I am frightened, and am astonished at being here rather than there; for there is no reason why here rather than there, now rather than then.» Blaise Pascal