Do you laugh or cry?
-
Came across this little parable and can't decide if it merely hits too close to home or if it cuts to the bone. Either way I can certainly relate. The Parable of the Two Programmers[^] Dan
Be clear about the difference between your role as a programmer and as a tester. The tester in you must be suspicious, uncompromising, hostile, and compulsively obsessed with destroying, utterly destroying, the programmer's software. ----- Boris Beizer
-
Came across this little parable and can't decide if it merely hits too close to home or if it cuts to the bone. Either way I can certainly relate. The Parable of the Two Programmers[^] Dan
Be clear about the difference between your role as a programmer and as a tester. The tester in you must be suspicious, uncompromising, hostile, and compulsively obsessed with destroying, utterly destroying, the programmer's software. ----- Boris Beizer
-
Came across this little parable and can't decide if it merely hits too close to home or if it cuts to the bone. Either way I can certainly relate. The Parable of the Two Programmers[^] Dan
Be clear about the difference between your role as a programmer and as a tester. The tester in you must be suspicious, uncompromising, hostile, and compulsively obsessed with destroying, utterly destroying, the programmer's software. ----- Boris Beizer
I don't get it.
-
Came across this little parable and can't decide if it merely hits too close to home or if it cuts to the bone. Either way I can certainly relate. The Parable of the Two Programmers[^] Dan
Be clear about the difference between your role as a programmer and as a tester. The tester in you must be suspicious, uncompromising, hostile, and compulsively obsessed with destroying, utterly destroying, the programmer's software. ----- Boris Beizer
ROFL! That is so funny because I see that all the time in web development. I can bid on a project and it will turn out that there are bids 10 times less and 10 times more. The end product I have seen from both sides, and honestly the code is just as crappy sometimes at the top level. I should make a site to post crappy code on with the company that did it, so people will start to take some responsibility. Hmm...hallofshamecode.com? :)
-
Came across this little parable and can't decide if it merely hits too close to home or if it cuts to the bone. Either way I can certainly relate. The Parable of the Two Programmers[^] Dan
Be clear about the difference between your role as a programmer and as a tester. The tester in you must be suspicious, uncompromising, hostile, and compulsively obsessed with destroying, utterly destroying, the programmer's software. ----- Boris Beizer
Some thoughts: I was recently criticized for taking a week to write a component. The client indicated that if this meant an average of one week per component, it would be unacceptable productivity and would kill the project. In many ways, the client was right. However, from my perspective, the component was well designed, documented, unit tested, and there was an initial proof of concept that I did as well because it wasn't necessarily a simple component if one looked at the longer term picture of maintainability and extensibility. So, there are really two conflicting goals here. The client's goal, justified because there are deadlines and product to get out which has a tangible impact on revenue. My goals, which were to create a testable, documented, maintainable and extensible component that in the long term would reduce costs (which, by the way, the client also recognizes as valuable). It's pretty clear that "income" and "cost" are really two different pieces of the puzzle, and the client's (or manager's) perspective has a definite impact on what is viewed as productive and effective. Another way to look at it is whether you're writing code to plan for the future or whether you're writing code to ship a product. In some ways, planning for the future assumes certain things--the code will need maintenance, there are probably going to be bugs, at some point the component may need to be extended. The "what if" scenario is not an easy sell under budget/time constraints, even if arguably the defensive programming approach is intended to ensure that the product actually does ship with a certain level of quality and can be updated later on. However, the "what if" scenarios aren't guaranteed to occur, and the resulting defensive programming can be viewed as jeopardizing the entire project. It's hard to reach a balance. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Some thoughts: I was recently criticized for taking a week to write a component. The client indicated that if this meant an average of one week per component, it would be unacceptable productivity and would kill the project. In many ways, the client was right. However, from my perspective, the component was well designed, documented, unit tested, and there was an initial proof of concept that I did as well because it wasn't necessarily a simple component if one looked at the longer term picture of maintainability and extensibility. So, there are really two conflicting goals here. The client's goal, justified because there are deadlines and product to get out which has a tangible impact on revenue. My goals, which were to create a testable, documented, maintainable and extensible component that in the long term would reduce costs (which, by the way, the client also recognizes as valuable). It's pretty clear that "income" and "cost" are really two different pieces of the puzzle, and the client's (or manager's) perspective has a definite impact on what is viewed as productive and effective. Another way to look at it is whether you're writing code to plan for the future or whether you're writing code to ship a product. In some ways, planning for the future assumes certain things--the code will need maintenance, there are probably going to be bugs, at some point the component may need to be extended. The "what if" scenario is not an easy sell under budget/time constraints, even if arguably the defensive programming approach is intended to ensure that the product actually does ship with a certain level of quality and can be updated later on. However, the "what if" scenarios aren't guaranteed to occur, and the resulting defensive programming can be viewed as jeopardizing the entire project. It's hard to reach a balance. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithAnother way to look at it is whether you're writing code to plan for the future or whether you're writing code to ship a product. This is how one of my managers recently summed this up ... "I don't want you to fix it, I want you to make it work." Think about that for awhile ... :sigh:
Any sufficiently gross incompetence is nearly indistinguishable from malice.
-
Another way to look at it is whether you're writing code to plan for the future or whether you're writing code to ship a product. This is how one of my managers recently summed this up ... "I don't want you to fix it, I want you to make it work." Think about that for awhile ... :sigh:
Any sufficiently gross incompetence is nearly indistinguishable from malice.
Blake Miller wrote:
I don't want you to fix it, I want you to make it work."
LOL! But often, fixing it can mean a rewrite/rearchitect, whereas, making it work can just mean getting the bugs, erm, fixed. The manager probably has the experience of programmers "fixing" the problem by rewriting and having that rewrite take a lot longer than anyone expected. Not that I'm taking sides with the manager. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Blake Miller wrote:
I don't want you to fix it, I want you to make it work."
LOL! But often, fixing it can mean a rewrite/rearchitect, whereas, making it work can just mean getting the bugs, erm, fixed. The manager probably has the experience of programmers "fixing" the problem by rewriting and having that rewrite take a lot longer than anyone expected. Not that I'm taking sides with the manager. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithOh that is EXACTLY what he meant. However, when a product only gets 'made to work' for 10 years and really 'needs a fixin', then the most recent maintenance programer is really in a bind. In this case, everyone thought the product was thread safe. A dual core pentium showed them all who was wrong...
Any sufficiently gross incompetence is nearly indistinguishable from malice.
-
Blake Miller wrote:
I don't want you to fix it, I want you to make it work."
LOL! But often, fixing it can mean a rewrite/rearchitect, whereas, making it work can just mean getting the bugs, erm, fixed. The manager probably has the experience of programmers "fixing" the problem by rewriting and having that rewrite take a lot longer than anyone expected. Not that I'm taking sides with the manager. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithThis reminds me of a client of ours. They approached the company to "upgrade" a system of theirs with some "minor features". Well, after 3 months of detailed analysis and design work, we sought a meeting with them to discuss the strategy. Basically, they could have the upgrade which would take about 14 months of work or we would write a new system that did what they wanted (which would be nice and extensible) and would take about 7 months (including testing). One of the managers there, not unreasonably, wanted to know why we were quoting double for the "upgrade". He was a bit shocked when we showed him the functional areas that we would have to unpick and heavily modify to work with the new business infrastructure that they were putting in place. It turned out that they had been making do with a "fix it" attitude for several years, and had actually instructed their users to change their business practices to work around the known deficiencies in the system. Anyway, we ended up having to apply the fixes to their existing codebase (despite warning them that the code had just about reached the end of its lifespan anyway). 3 months after go-live, we get a phone call. Their business process has changed, could we change the code again. After discussing the requirements with them, it became apparent to both sides that upgrading wouldn't work. The end result - 2 years down the line from the original quote, we ended up having to do the rewrite anyway. Ironically, had they gone with the rewrite in the first place, it would only have taken a month to upgrade it. Ho hum. Crazy from the clients point of view, but they didn't listen and it did bring a lot of revenue into the company.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
-
Oh that is EXACTLY what he meant. However, when a product only gets 'made to work' for 10 years and really 'needs a fixin', then the most recent maintenance programer is really in a bind. In this case, everyone thought the product was thread safe. A dual core pentium showed them all who was wrong...
Any sufficiently gross incompetence is nearly indistinguishable from malice.
Reminds me of a time a few years back I was asked to add a feature to a program and I noticed some rather odd SQL. I asked the last guy who had been maintaining the program before that and he said that that was how it was when he got it. "If it ain't broke, don't fix it." Well I darn well fixed it, and the resulting program, with my new feature, ran in a quarter of the time (10 min rather than 40 min).
-
Came across this little parable and can't decide if it merely hits too close to home or if it cuts to the bone. Either way I can certainly relate. The Parable of the Two Programmers[^] Dan
Be clear about the difference between your role as a programmer and as a tester. The tester in you must be suspicious, uncompromising, hostile, and compulsively obsessed with destroying, utterly destroying, the programmer's software. ----- Boris Beizer
That's why Charles (and other competent programmers like him) should be working for themselves, or for a small company where there is no such "management structure". When he is his own boss, decides his own priorities and work schedule and is only judged by whether or not his programs do what is required of them he will be better valued. The rest of the world will just have to live with the injustice of Alans being valued for their ability to meet management expectations despite their inability to achieve any goals (or program their way out of a paper bag). GO CHARLES!
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
-
Came across this little parable and can't decide if it merely hits too close to home or if it cuts to the bone. Either way I can certainly relate. The Parable of the Two Programmers[^] Dan
Be clear about the difference between your role as a programmer and as a tester. The tester in you must be suspicious, uncompromising, hostile, and compulsively obsessed with destroying, utterly destroying, the programmer's software. ----- Boris Beizer
if there would be next sequel definitely Charles would be the winner the intellectual skills and knowledge he had will make him rise and Alan will changed into a boss ( voted 1 by staff ) and a fake shell of knowledge doesn't go for long :):)
It is Good to be Important but! it is more Important to be Good