November 15, 2011 at 5:46 am
JJ B (11/14/2011)
I thought this was a great editorial and appreciated the good reminder.I also think this is a walking advertisement for thoroughly documenting the "why" of code as much as possible. If you explain why you are doing X instead of Y, you can make it a whole lot easier for the future programmer to safely make changes/eliminate the guess-work on what the heck you were thinking.
A nice side-benefit is that by documenting the "why" of your code, you can effectively preempt *some* criticism - even by your future self.
I think you hit on two very important points - comments and documentation. Personally, I'm not very good at the documentation piece. I feel that I'm getting better but not up to the level I'd like to be at yet. The commenting piece I've gotten better at by learning the hard way. In school, I always ended up working on solo projects. Even now in my career, most of my projects are completed on my own. The key difference between the me in school and the me now is that now I'm very aware of the fact that at some point, someone else in my group will need to troubleshoot my code and I have the power to make that a little easier for them by adding appropriate comments.
I'd also like to add that debugging tools are very useful. I think of this more for the application side, but the point is still valid. When something goes wrong - and we all know it always does - it's very handy to have some type of debug information available so you know where to start looking for the problem.
November 15, 2011 at 6:19 am
JJ B (11/14/2011)
I thought this was a great editorial and appreciated the good reminder.I also think this is a walking advertisement for thoroughly documenting the "why" of code as much as possible. If you explain why you are doing X instead of Y, you can make it a whole lot easier for the future programmer to safely make changes/eliminate the guess-work on what the heck you were thinking.
A nice side-benefit is that by documenting the "why" of your code, you can effectively preempt *some* criticism - even by your future self.
Good point.
The policy I set for comments and documentation of all database objects and code is "Why, not What". I find it much more useful to know what business rule is being implemented than to have a comment that says "-- Inserting data from table".
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 16, 2011 at 1:42 pm
I despise poorly written code and the reasons are many:
* usually consumes (wastes) precious resources (memory, CPU, I/O)
* exhibits poor concurrency
* poor scalability
* poor documentation
The typical argument I hear for a crappy design as well as crappy impleementation (code) is something like: "we didn't have time to do it right, we had to hurry up and get something into production for the customer.." for the customer. that must be something like " for the children..."
Well of course that contention is merely an excuse for the incompetence of the person(s) that conceived of the design and wrote the code. It really doesn't take any longer to put a well designed product into production that it does to put a POS into production. When you consider all the man-hours spent fixing bugs, applying band-aids and other hacks to make it work and keep it running by countless people its a net loss.
That's my opinion and I'm sticking to it.
The probability of survival is inversely proportional to the angle of arrival.
November 16, 2011 at 2:20 pm
sturner (11/16/2011)
I despise poorly written code and the reasons are many:It really doesn't take any longer to put a well designed product into production that it does to put a POS into production.
Really? I can put a POS into production pretty darn fast. But truly understanding the requirements and capturing them properly in the design while maintaining low coupling, high cohesion and optimal performance while remaining scalable is another matter altogether and takes much longer.
My current work environment brings many tools to bear to make sure we do not develop bad designs or write bad code. We use these tools religously and they serve us well: rapid prototyping, TDD, CI and Agile (specifically SCRUM). We are not perfect with some of these tools but we try to improve week to week, month to month and year to year.
Anyways, I get the point (I'm quoting Mary Poppendieck here):
Build the Right Thing
Build the Thing Right
November 17, 2011 at 2:59 am
sturner (11/16/2011)
I despise poorly written code and the reasons are many:* usually consumes (wastes) precious resources (memory, CPU, I/O)
* exhibits poor concurrency
* poor scalability
* poor documentation
The typical argument I hear for a crappy design as well as crappy impleementation (code) is something like: "we didn't have time to do it right, we had to hurry up and get something into production for the customer.." for the customer. that must be something like " for the children..."
Well of course that contention is merely an excuse for the incompetence of the person(s) that conceived of the design and wrote the code. It really doesn't take any longer to put a well designed product into production that it does to put a POS into production. When you consider all the man-hours spent fixing bugs, applying band-aids and other hacks to make it work and keep it running by countless people its a net loss.
In all this, you're making a fundamental assumption that efficient use of the resources you mentioned is at the top of the list of business priorities in your company.
Over the years I've met very few people I've been convinced are happy turning in bad work; most people want to do a good job. If that's true then every cludge I come across has a story behind it to help explain why that was the best that person could do at that time with the time, knowledge and resources then available and within the scope defined at that point. That doesn't necessarily excuse the cludge, but it may not be the person who put it in who is ultimately at fault, and I refuse to damn someone for doing their best.
Semper in excretia, suus solum profundum variat
November 17, 2011 at 6:43 am
majorbloodnock (11/17/2011)
That doesn't necessarily excuse the cludge, but it may not be the person who put it in who is ultimately at fault, and I refuse to damn someone for doing their best.
I don't buy it. Every bad system design and.or implementation I've ever run into could have been avoided or improved upon with little or no extra effort during its inception. One can only assume that the person who did it either did not care or was not competent enough to know any better.
A few times when I've had to patch fix/hack an existing system in non-optimal way, I left some comment verbiage in the code as a warning/mea culpa to the poor soul that might have to further modify it down the road.
The probability of survival is inversely proportional to the angle of arrival.
November 17, 2011 at 6:50 am
sturner (11/16/2011)
I despise poorly written code and the reasons are many:* usually consumes (wastes) precious resources (memory, CPU, I/O)
* exhibits poor concurrency
* poor scalability
* poor documentation
The typical argument I hear for a crappy design as well as crappy impleementation (code) is something like: "we didn't have time to do it right, we had to hurry up and get something into production for the customer.." for the customer. that must be something like " for the children..."
Well of course that contention is merely an excuse for the incompetence of the person(s) that conceived of the design and wrote the code. It really doesn't take any longer to put a well designed product into production that it does to put a POS into production. When you consider all the man-hours spent fixing bugs, applying band-aids and other hacks to make it work and keep it running by countless people its a net loss.
That's my opinion and I'm sticking to it.
I guess I shouldn't say this, but: if that last sentence means that regardless of any evidence that shows up you will stick to your opinion, then your opinion (whether right or wrong) is worthless, because no-one in his right mind would pay the slightest attention to any opinion of yours.
If you don't understand that, please go and be a politician and keep well aways from IT and Computing where you could do a lot of harm (of course you could as a politician too, but all politicians do that so you'd make politics no worse).
Regardless of that, your opinion that computer memory, cpu and io are precious resources, presumably more precious than people's time and effort, sufficiently precious that something that is bug free, works, and performs well enough to do the job but not much better is by comparisin worthless is so outmoded that it was known to be utterly wrong probably before you touched your first computer (certainly it was well known in 1970 - it had been used in management textbooks as an example of what a successful computer company should never do for a few years by then). Anyone who spends five man years (call it a million dollars) to find a faster algorithm for calculation X which is CPU-bound and takes 5.2 seconds on a 2GHz CPU but needs to be done in 5 seconds dead instead of just upgrading to a more appropriate CPU (extra cost maybe five dollars) is a spendthrift idiot unless he knows he's going to need so many that even on a discounted cash-flow basis he can cover the extra development cost in a reasonable time (remembering to cost in the fact that for a year or so he has to either use the faster chip or not release the product - unless he's found a way of getting babies in less that 9 months by throwing lots of women at the problem - and also remembering to include the "lost opportunity" cost of not using those 5 man years on something a bit more profitable), and any company which makes a habit of that sort of stupidity quickly finds itself in serious financial trouble.
Tom
November 17, 2011 at 6:51 am
sturner (11/17/2011)
majorbloodnock (11/17/2011)
That doesn't necessarily excuse the cludge, but it may not be the person who put it in who is ultimately at fault, and I refuse to damn someone for doing their best.I don't buy it. Every bad system design and.or implementation I've ever run into could have been avoided or improved upon with little or no extra effort during its inception. One can only assume that the person who did it either did not care or was not competent enough to know any better.
A few times when I've had to patch fix/hack an existing system in non-optimal way, I left some comment verbiage in the code as a warning/mea culpa to the poor soul that might have to further modify it down the road.
But you don't have to buy it. With respect, unless you own the business or you were one of the sponsors of the original implementation, it's not your opinion that counts.
And if you do assume the person who did it wasn't yet competent enough to know better, you also have to assume it was a business decision to put them into that position and accept the risk.
Semper in excretia, suus solum profundum variat
November 17, 2011 at 7:02 am
L' Eomot Inversé (11/17/2011)
sturner (11/16/2011)
I despise poorly written code and the reasons are many:* usually consumes (wastes) precious resources (memory, CPU, I/O)
* exhibits poor concurrency
* poor scalability
* poor documentation
The typical argument I hear for a crappy design as well as crappy impleementation (code) is something like: "we didn't have time to do it right, we had to hurry up and get something into production for the customer.." for the customer. that must be something like " for the children..."
Well of course that contention is merely an excuse for the incompetence of the person(s) that conceived of the design and wrote the code. It really doesn't take any longer to put a well designed product into production that it does to put a POS into production. When you consider all the man-hours spent fixing bugs, applying band-aids and other hacks to make it work and keep it running by countless people its a net loss.
That's my opinion and I'm sticking to it.
I guess I shouldn't say this, but: if that last sentence means that regardless of any evidence that shows up you will stick to your opinion, then your opinion (whether right or wrong) is worthless, because no-one in his right mind would pay the slightest attention to any opinion of yours.
If you don't understand that, please go and be a politician and keep well aways from IT and Computing where you could do a lot of harm (of course you could as a politician too, but all politicians do that so you'd make politics no worse).
Regardless of that, your opinion that computer memory, cpu and io are precious resources, presumably more precious than people's time and effort, sufficiently precious that something that is bug free, works, and performs well enough to do the job but not much better is by comparisin worthless is so outmoded that it was known to be utterly wrong probably before you touched your first computer (certainly it was well known in 1970 - it had been used in management textbooks as an example of what a successful computer company should never do for a few years by then). Anyone who spends five man years (call it a million dollars) to find a faster algorithm for calculation X which is CPU-bound and takes 5.2 seconds on a 2GHz CPU but needs to be done in 5 seconds dead instead of just upgrading to a more appropriate CPU (extra cost maybe five dollars) is a spendthrift idiot unless he knows he's going to need so many that even on a discounted cash-flow basis he can cover the extra development cost in a reasonable time (remembering to cost in the fact that for a year or so he has to either use the faster chip or not release the product - unless he's found a way of getting babies in less that 9 months by throwing lots of women at the problem - and also remembering to include the "lost opportunity" cost of not using those 5 man years on something a bit more profitable), and any company which makes a habit of that sort of stupidity quickly finds itself in serious financial trouble.
You are free to express your convoluted opinion and likewise anyone ".. in his right mind" is free to pay attention to it.
The probability of survival is inversely proportional to the angle of arrival.
Viewing 9 posts - 46 through 53 (of 53 total)
You must be logged in to reply to this topic. Login to reply