The Daily WTF: Curious Perversions in Information Technology

the real wtf fool · 2010-03-09 Reply Admin

luis.espinal:
Any pristine and shinny web thingie that you just created becomes legacy the moment you are asked to make a change to it. You don't ditch your fully functioning car and buy a new one just because you want (or need) to update its stereo system, do you?

Um well... http://www.visit4info.com/advert/Bluetooth-Duet-with-Peugeot-207-Verve-Peugeot-207-Range/68782 Peugeot seems to think so!

We are currently living in a massively disposable society which promotes the idea that new&shiny==wonderful and old/repair==baaad. That seems to be coming through in the current attitude of many software developers too: a lot of job ads now promote the fact you will be working on a greenfield project with 'none of that horrible crusty legacy code to deal with' as the sub-text.

I'm currently working on a project which is at least 80% legacy code (from 1990-ish). Most of it is pretty horrendous but the main cause of that seems to me to be that devs have used the principle of least change when adding new functionality/fixing bugs, so the original clean structure has become a tangled mess. If there were some kind of automated regression testing in place I think devs would have been more willing to refactor when they put new code in place and less fearful of breaking the system. Unit test & some level of automated integration testing would have helped greatly. Of course the challenge now is that the design of exisiting components doesn't lend itself to unit tests.

2010-03-09 Reply Admin

Rev. Jimmy Jones:
Agreed. Dont you know what the first "D" stands for?
You didn't actually provide any counter argument other than "your not doing it right". There are actual studies that show no correlation between using TDD and improving quality. There is at least one flawed study that attempts to prove (and fails) that is does improve quality. I won't post the links here but you can do the research yourself if you care.

Yes, it stands for "Driven". I don't really see how that's relevant.

I don't NEED to provide any other counter arguments, if you're crap at designing, don't know much about patterns, refactoring, IoC, SOLID, etc... TDD isn't going to help you. If you write shit code, using TDD will just allow you to write more shit code.

If you write good code TDD will probably make it even better, and I don't need to refer to any studies of indian fast-track MS Certified developers to prove that, because it worked for me - and that's all the proof that I need.

2010-03-09 Reply Admin

X:
What I've found out is the TDD, BDD, Agile, etc are really religions. If you don't actually believe in them from the bottom of your heart they don't work.

Are you saying that Christianity, or any religion for that matter, will become true if I just believe in it enough? Did you learn theology from Walt Disney or what?

forbjok · 2010-03-09 Reply Admin

At least, if that test fails you'll know something's REALLY wrong.

2010-03-09 Reply Admin

So very wrong.

Developers make working code, testers test functionality. If making working code requires you to write some code to exercise that code, that's also your work. Don't walk up to a developer telling him to test, that won't and will never work.

2010-03-09 Reply Admin

300 developers? THIS! IS! JAVA!!!

sorry...

2010-03-09 Reply Admin

Can somebody come up with a formula to describe the point at which the comments descend into trolling and counter-trolling? I usually find it's around about half way down the second page - which where I generally stop reading.

Back on topic, if you have any pride in your work whatsoever, you'll use every tool you can lay your hands on that will help you produce quality code.

2010-03-09 Reply Admin

Norris:
Back on topic, if you have any pride in your work whatsoever, you'll use every tool you can lay your hands on that will help you produce quality code.

If this were true then several programming languages wouldn't even exist. VB anyone?

2010-03-09 Reply Admin

This comment should be not outlawed if not outlawing the comment does not make sense.

2010-03-09 Reply Admin

Dave G.:
I've had people try to sell me on unit tests before. I've heard all the alleged benefits of being able to effortlessly refactor your code because the tests will tell you if anything breaks, or of being able to see whether any new functionality causes regressions, all governed by the all-knowing unit tests that sit there as sentinels over your code.
It's bollocks. It's theoretical hogwash. I have never seen a magical unit test that can be written once and serve its purpose in that form without requiring maintenance. When the application changes due to a change in requirements, or even just to a mild refactoring of the code, the unit tests have to change with them.

And that's the rub. The unit tests themselves have to be maintained. That might seem fine at the start of a project, but once you have a load of unit tests on a project of sufficient maturity, you spend as much of your time maintaining the unit tests as the actual code!

Eventually, timeline pressures force you to abandon the unit tests entirely because you just have NO TIME to keep maintaining them. You get unit tests deleted or commented out because you don't have time to dick around with them.

In that case, you were better off not wasting the time writing the unit tests in the first place.

Customers do not care about unit tests. They care about getting a working product, on time and on budget. You can argue all you like that unit tests help to deliver that, but in my experience they are worthless. They just weigh too heavily on your resources towards the end of the project. You have a deadline, a project to deliver, and you are running a business, not some undergrad crap in college.

Unit tests do not work in the real world. In theoretical project world, your schedule would always be reasonable, and you would not be rushing at the end to cram in just-one-more-feature or fix some stupid issue that only occurs when they deploy it on Windows Server with service pack 1 with mcaffee version 5.4.33 and a pink elephant in the room. In reality, projects don't work that way. They never work that way.

This article conveys my feelings better than I could. I encourage everyone who has either voluntarily drank the unit-testing kool-aid or had it rammed down their throats to read it.

http://blogs.msdn.com/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx

I can think of a very few specific situations where you might want to use them, but my default is to reject them. Someone would have to prove to me, conclusively, why they would be good in a particular case, and explain to me why they won't become an unbearable burden at the end. I won't waste my time with them otherwise.

That article is riddled with assumptions and logical flaws, as is your post.

Don't like Unit tests? Don't write them!

Don't like programming? Find a new profession.

Don't like personal responsibility or project accountability? Agree to squeeze one more feature or untested hardware configuration into your release post-RTD.

These are all your problems, and anyone's who thinks in broken chords as you do.

Unit tests are about stating business requirements first, and encapsulating edge cases second. If your business facts change, you damn well better change the requirements on the code!

Whether you keep those requirements in .txt or .doc or .ppt or .xls or .wtf, they will get stale if you don't maintain them. The benefit of keeping the requirements themselves in repeatable code is the bi-directional enforcement; not: "Have i made trivial mistakes?", but: "Does it do what i was engaged to make it do".

Oh, and then of course, there're the poor miserable sods that follow in your wake, adding to or cleaning up the mess you left behind.

You know. The people that post your "last-minute fixes" ...here.

2010-03-09 Reply Admin

Anonymous:
X:
What I've found out is the TDD, BDD, Agile, etc are really religions. If you don't actually believe in them from the bottom of your heart they don't work.
Are you saying that Christianity, or any religion for that matter, will become true if I just believe in it enough? Did you learn theology from Walt Disney or what?

This post highlights the COMPLETE LACK of UNDERSTANDING even first level LOGIC [which should be taught in Grade School - Preferably in Elementary School [ages 6-12 approx]

if A then B does NOT imply: if B then A nor if NOT A then not B.

It simply amazes me that people with such a lack of basic knowledge are even ALLOW NEAR computers or forums!

2010-03-09 Reply Admin

The original article has this quote, "Less bugs, less time manual testing,"

It is FEWER bugs, less time testing. That is, unless you've found a way to create half a bug...

2010-03-09 Reply Admin

TheCPUWizard:
Anonymous:
X:
What I've found out is the TDD, BDD, Agile, etc are really religions. If you don't actually believe in them from the bottom of your heart they don't work.
Are you saying that Christianity, or any religion for that matter, will become true if I just believe in it enough? Did you learn theology from Walt Disney or what?

This post highlights the COMPLETE LACK of UNDERSTANDING even first level LOGIC [which should be taught in Grade School - Preferably in Elementary School [ages 6-12 approx]

if A then B does NOT imply: if B then A nor if NOT A then not B.

It simply amazes me that people with such a lack of basic knowledge are even ALLOW NEAR computers or forums!

You're right but I don't think it is due to lack of knowledge. It is probably just some moron trolling around.

And the quality of trolling is on the low lately. They're throwing any stupid statement these days just to try and provoke a reaction.

T0pCod3r, wherefore art thou?

2010-03-09 Reply Admin

TheCPUWizard:
This post highlights the COMPLETE LACK of UNDERSTANDING even first level LOGIC [which should be taught in Grade School - Preferably in Elementary School [ages 6-12 approx]
if A then B does NOT imply: if B then A nor if NOT A then not B.

It simply amazes me that people with such a lack of basic knowledge are even ALLOW NEAR computers or forums!

Well done for your truly heroic lack of humour. Enjoy dying alone.

2010-03-09 Reply Admin

The real WTF is in six months time not being able to do anything else but force a cargo cult methodology on people. For new projects it might be ok, to force a unit testing with integration approach on an existing project is just madness.

2010-03-09 Reply Admin

NASDAQ and Philadelphia stock exchange merged not long ago. Had a friend there helping out. Philly people asked about QA. NASDAQ, said, "QA? We don't have QA. You write your code, You test your code. You deploy your code. You make too many mistakes, you don't work here anymore."

Interestingly, I am at DevNexus where CTO of ICE made the statement that the NASDAQ's engine runs as a single thread on a single machine, on Java and they have submilli transaction rates.

Is this not a shining indictment of modern software engineering and its constant kowtowing to the methodology de jour.

2010-03-09 Reply Admin

Exactly this.

2010-03-09 Reply Admin

the beholder:
TheCPUWizard:
Anonymous:
X:
What I've found out is the TDD, BDD, Agile, etc are really religions. If you don't actually believe in them from the bottom of your heart they don't work.
Are you saying that Christianity, or any religion for that matter, will become true if I just believe in it enough? Did you learn theology from Walt Disney or what?

This post highlights the COMPLETE LACK of UNDERSTANDING even first level LOGIC [which should be taught in Grade School - Preferably in Elementary School [ages 6-12 approx]

if A then B does NOT imply: if B then A nor if NOT A then not B.

It simply amazes me that people with such a lack of basic knowledge are even ALLOW NEAR computers or forums!
You're right but I don't think it is due to lack of knowledge. It is probably just some moron trolling around.

And the quality of trolling is on the low lately. They're throwing any stupid statement these days just to try and provoke a reaction.

T0pCod3r, wherefore art thou?

Why is T0pCod3r?

Because there was a void that needed to be filled with high-quality trolls, of course!

But that question itself seems trollish...unless you were responding to a flame about knowledge and education with a literary comprehension fail... and were actually asking about his (meta/)physical locus?

2010-03-09 Reply Admin

TheCPUWizard:
Anonymous:
X:
What I've found out is the TDD, BDD, Agile, etc are really religions. If you don't actually believe in them from the bottom of your heart they don't work.
Are you saying that Christianity, or any religion for that matter, will become true if I just believe in it enough? Did you learn theology from Walt Disney or what?

This post highlights the COMPLETE LACK of UNDERSTANDING even first level LOGIC [which should be taught in Grade School - Preferably in Elementary School [ages 6-12 approx]

if A then B does NOT imply: if B then A nor if NOT A then not B.

It simply amazes me that people with such a lack of basic knowledge are even ALLOW NEAR computers or forums!

Welcome to the new internets.

On your hurk, you'll find facebook, AOLolcats and fox "news". On your kwan, you'll notice /b/, fark and digg.

Now gtfo my /r/ and TDWTF.

2010-03-09 Reply Admin

Test Driven Development is more about efficient development than code quality. Luckily, with more efficient development, you have more resources to devote to other forms of testing.

Unit tests are to your code project as a scaffold is to a construction project. They allow you to build a unit of the application without needing the rest of the program to be implemented.

2010-03-09 Reply Admin

quisling:
That article is riddled with assumptions and logical flaws, as is your post.

Why don't you point some of them out then?

quisling:
Don't like Unit tests? Don't write them!

I don't.

quisling:
Don't like programming? Find a new profession.

I love programming. I don't love wasting my time on something which is pointless.

quisling:
Don't like personal responsibility or project accountability? Agree to squeeze one more feature or untested hardware configuration into your release post-RTD.

Yes, because programmers are ALWAYS the ones that decide which features actually end up shipping. The business NEVER comes down and insists that something MUST be done because "it's critical".

quisling:
These are all your problems, and anyone's who thinks in broken chords as you do.

You seem to live in a magical world where programmers are the ones in charge of the project, as opposed to the business managers and the clients who are paying for it.

Remember theoretical project world that I spoke about? You've living there.

quisling:
Unit tests are about stating business requirements first, and encapsulating edge cases second. If your business facts change, you damn well better change the requirements on the code!

Business requirements are stated in the SRS which is where they belong. Recoding the business requirements as unit tests wastes time and constrains your design up front. That's fine if nothing ever changes, but once you have a mammoth suite of tests constraining everything, every change is now much more difficult to make.

The key to project success is flexibility, the ability to adapt your software quickly. Any experienced professional knows that. So why you would advocate a practice which actively inhibits flexibility right from the start is beyond me.

quisling:
Whether you keep those requirements in .txt or .doc or .ppt or .xls or .wtf, they will get stale if you don't maintain them. The benefit of keeping the requirements themselves in repeatable code is the bi-directional enforcement; not: "Have i made trivial mistakes?", but: "Does it do what i was engaged to make it do".

The requirements STILL have to be stated in some form of document somewhere. The client isn't going to sign off on your unit test suite and go 'yep, go for it'. So now you have TWO places where the requirements must be updated, AND the code must be updated too! Where on earth do you get the time to do all this? In theoretical project world, of course.

Furthermore, it should be obvious that more code means more bugs. Unit tests can actually introduce bugs themselves. It seems test advocates expect programmers to make simple, basic errors in the code they write - the sort of errors unit tests would catch - and THEN expect those same programmers to write pristine error free unit tests.

So again, these perfect unit tests are absolutely theoretical. Theoretical hogwash in theoretical project world.

quisling:
Oh, and then of course, there're the poor miserable sods that follow in your wake, adding to or cleaning up the mess you left behind.

I don't know about you, but I write good code. I am capable of ensuring my code meets the requirements with the use of a debugger and the ability to read a spec, or call a customer for clarification. I don't need my hand held by tests as I am responsible enough to get it done right the first time.

quisling:
You know. The people that post your "last-minute fixes" ...here.

Last minute fixes are a project reality in anything but the most trivial applications. Maybe in theoretical project world, where you come from, they don't exist, but here in reality they do.

2010-03-09 Reply Admin

James:
Bim Job:
Or, and quite appropriately (I apologise for the top-quoting, although I have no earthly idea why I should do so):
Bim Job:
Mr. Wint: If at first you don't succeed Mr. Kidd...? Mr. Kidd: Try, try again, Mr. Wint.
Courtesy of Diamonds are forever, here.

Sorry to go off-topic but...

...that movie was a huge WTF.

And I'm a "Sean Connery is the only James Bond" kind of fan. Something about that movie was just out out congruity with the other Saltzman/Broccoli/Connery Bond films.

Well, I liked the bomb.

Also an early introduction to homosexuality, for those who like that sort of thing.

2010-03-09 Reply Admin

sino:
TheCPUWizard:
Anonymous:
X:
What I've found out is the TDD, BDD, Agile, etc are really religions. If you don't actually believe in them from the bottom of your heart they don't work.
Are you saying that Christianity, or any religion for that matter, will become true if I just believe in it enough? Did you learn theology from Walt Disney or what?

This post highlights the COMPLETE LACK of UNDERSTANDING even first level LOGIC [which should be taught in Grade School - Preferably in Elementary School [ages 6-12 approx]

if A then B does NOT imply: if B then A nor if NOT A then not B.

It simply amazes me that people with such a lack of basic knowledge are even ALLOW NEAR computers or forums!
Welcome to the new internets.

On your hurk, you'll find facebook, AOLolcats and fox "news". On your kwan, you'll notice /b/, fark and digg.

Now gtfo my /r/ and TDWTF.

Darn, no. Them's gotta be better than that.

2010-03-10 Reply Admin

Dave G.:
quisling:
That article is riddled with assumptions and logical flaws, as is your post.
Why don't you point some of them out then?

A reasonable request; and you seem yet like a reasonable person. I will donate some of my time to you.

Assumptions (Erroneous):

magical unit test that can be written once and serve its purpose in that form without requiring maintenance

you spend as much of your time maintaining the unit tests as the actual code

timeline pressures force you to abandon the unit tests entirely

unit tests deleted or commented out because you don't have time to dick around with them

[unit tests]weigh too heavily on your resources towards the end of the project

rushing at the end to cram in just-one-more-feature or fix some stupid issue that only occurs when they deploy it on Windows Server with service pack 1 with mcaffee version 5.4.33 and a pink elephant in the room

etc...

Logic Fails:

once you have a load of unit tests on a project of sufficient maturity, you spend as much of your time maintaining the unit tests as the actual code

you were better off not wasting the time writing the unit tests in the first place

Unit tests do not work in the real world

In reality, projects don't work that way.

you just have NO TIME to keep maintaining them

etc...

On to the rest of your contentions, then!

Dave G.:
quisling:
Don't like Unit tests? Don't write them!
I don't.

Clearly. But i suspect what you learned to hate were actually integration tests in masquerade.

Dave G.:
quisling:
Don't like programming? Find a new profession.
I love programming. I don't love wasting my time on something which is pointless.

This is a first order Logic Fail, unless i mistake your context: Consuming your own APIs is neither pointless nor a waste of time.

Dave G.:
quisling:
Don't like personal responsibility or project accountability? Agree to squeeze one more feature or untested hardware configuration into your release post-RTD.
Yes, because programmers are ALWAYS the ones that decide which features actually end up shipping. The business NEVER comes down and insists that something MUST be done because "it's critical".

You control your own destiny. If you let this happen, you deserve your "real world". These types of shenanigans will only accelerate if you endorse them as you describe.

Dave G.:
You seem to live in a magical world where programmers are the ones in charge of the project, as opposed to the business managers and the clients who are paying for it.
Remember theoretical project world that I spoke about? You've living there.

Q: If you were asked to deliver a software project without a project manager, could you do it?

A: Probably, though less comfortably than with. (Caveat: some people are thoroughly incapable of dealing with other humans. As reference, see this comment board.)

Q: If a project manager were asked to deliver a software project without any devs, could they?

A: Highly unlikely. (Caveat: certain exceptions can be made for Dev-turned-PM, but this is a dishonest career path, and it is unlikely such a person was ever a viable developer. Even then, it's usually been so long since the Dev->PM abortion has thought in terms of logic rather than resources that it's unlikely they will deliver anything at all, let alone of value.)

You are in charge. You are the talent.

If a project manager mismanages my project and blames me for it, that's the last time i work with that project manager. If an account or business manager doesn't spell out deliverables (success criteria) with a client and attach cost values to them after consulting with the devs who will be working on the project, i will not work with them a first time. Theoretical project world is actually a step down from where i live and work, my dogmatically stubborn friend.

Dave G.:
quisling:
Unit tests are about stating business requirements first, and encapsulating edge cases second. If your business facts change, you damn well better change the requirements on the code!
Business requirements are stated in the SRS which is where they belong. Recoding the business requirements as unit tests wastes time and constrains your design up front.

The SRS is not consumable by maintenance developers, or cave-dwelling experts, or anyone not versed in marketing speech. If any of your devs are versed in marketing speech, FIRE THEM. Their logic modules are already compromised.

Dave G.:
The key to project success is flexibility, the ability to adapt your software quickly. Any experienced professional knows that.

Absolutely correct.

Dave G.:
So why you would advocate a practice which actively inhibits flexibility right from the start is beyond me.

Ooh, you were soooo close. Nope. They don't inhibit flexibility, they document usage. Which is to say, they preclude the need for flexibility when you start by consuming (excercising, some call it) the code from the perspective of your result down, rather than from your framework up. Not to mention the time you save not implementing useless shit that you then claim to need to be flexible enough to change.

Dave G.:
quisling:
Whether you keep those requirements in .txt or .doc or .ppt or .xls or .wtf, they will get stale if you don't maintain them. The benefit of keeping the requirements themselves in repeatable code is the bi-directional enforcement; not: "Have i made trivial mistakes?", but: "Does it do what i was engaged to make it do".
The requirements STILL have to be stated in some form of document somewhere. The client isn't going to sign off on your unit test suite and go 'yep, go for it'.

Again, correct.

Dave G.:
So now you have TWO places where the requirements must be updated, AND the code must be updated too!

Again, sooooo close. The requirements "doc" is handled by the person that gathers the requirements and attaches monetary estimates to them. It's called division of labor, and enforces accountability on the behalf of the often otherwise hapless layers of middle management between you (me) and success.

Demand they do their part. Ensure they do it correctly by refusing half-assed results. They refuse half-assed results from you, why shouldn't you require error-free requirements?

Dave G.:
Where on earth do you get the time to do all this? In theoretical project world, of course.

If the customer requested a feature or change outside of the original scope, that feature or change will be additive in time and cost. If it complicates or invalidates previous work, that is noted, and estimated.

Dave G.:
Furthermore, it should be obvious that more code means more bugs. Unit tests can actually introduce bugs themselves.

Yes, that second part is correct. However, more code does not explicitly mean more bugs, just more potential, or opportunity for bugs.

Dave G.:
It seems test advocates expect programmers to make simple, basic errors in the code they write - the sort of errors unit tests would catch - and THEN expect those same programmers to write pristine error free unit tests.

Well, no. As i stated, the first goal of unit tests is verifying functionality (happy path usage) in a manner compatible with proper code design (Isolation of Concerns). Secondary goals include verifying known or discovered edge cases and code coverage (mostly conditional branching); also, surfacing emergent side effects. This last one is part of happy path validation AND edge case verification.

I'm guessing your sour experience has been caused by "test advocates" insisting that "unit" tests prove the system is error-free. This is simply not true.

Dave G.:
So again, these perfect unit tests are absolutely theoretical. Theoretical hogwash in theoretical project world.

Yes, "perfect" unit tests probably are theoretical. Especially in the manner you describe them. But i suspect you're doing it wrong, probably through no fault of your own, but rather because of a misguided demonstration or explanation of purpose.

Dave G.:
quisling:
Oh, and then of course, there're the poor miserable sods that follow in your wake, adding to or cleaning up the mess you left behind.
I don't know about you, but I write good code. I am capable of ensuring my code meets the requirements with the use of a debugger and the ability to read a spec, or call a customer for clarification. I don't need my hand held by tests as I am responsible enough to get it done right the first time.

Note that i was talking about the people that come after you. In-house developers, juniors on the maintenance team, new hires unfamiliar with the project or your intent at the time. Perhaps you've noticed that a good number of snippets that end up here probably started as "good code", but mutated through path of least resistance changes into hellish abominations devoid of reason and intent.

But i'm sure they were originally written in a clear manner by capable developers like you, who thoroughly exercised every code path in a debugger.

...well, at the time.

Dave G.:
quisling:
You know. The people that post your "last-minute fixes" ...here.
Last minute fixes are a project reality in anything but the most trivial applications. Maybe in theoretical project world, where you come from, they don't exist, but here in reality they do.

Take control of your destiny, friend.

They can only do this to you when you yourself are complicit in the crime.

If it makes any difference to you, I was squarely in the unit-tests-are-for-suckers camp not more than three years ago. I was firmly of the opinion that unit tests were doing nothing but encouraging mediocrity; lowering the barrier of entry to a field i already perceived to be flush with amateurs and hacks.

Note this site, and the koff "dearth" koff of wtf-ey submissions.

It wasn't until i met a few truly brilliant programmers who managed to explain to me the value of determining usage in the terms of business facts (true requirements) before determining the implementation thereof, that i was even willing to listen to anyone on the subject.

Since then, i've learned that the value unit tests provide actually frees me to be more creative and flexible--not less--by removing from my brain space the dead weight of the implementation details of every intricate component of each highly complex system.

But, hey. YMMV.

XD

Waaaaay TL;DR:

Create the reality you want to work in.

Stop trying to be a hero. They'll bleed you dry.

Unit tests aren't magical guardians. They are a tool.

Like any tool, you can misuse them to great frustration.

Try to avoid that.

Cbuttius · 2010-03-10 Reply Admin

Developers do not want to write unit tests because then it might be easy for other developers to maintain, putting their own jobs at risk when currently they are the only ones who know how their code works and will know that nobody else dare change things in case they break something. But if there are tests then it leaves their code open to change and to be outsourced.

2010-03-10 Reply Admin

Cbuttius:
Developers do not want to write unit tests because then it might be easy for other developers to maintain, putting their own jobs at risk when currently they are the only ones who know how their code works and will know that nobody else dare change things in case they break something. But if there are tests then it leaves their code open to change and to be outsourced.

This is an incredibly salient argument. But an intensely dishonest attitude.

Whether you espouse or but describe the attitude is immaterial (though i suspect the latter):

Aristotle:
It is the mark of an educated mind to be able to entertain a thought without accepting it.

I would counter this attitude as i find it with:

Ayn Rand (Atlas Shrugged):
There's nothing of any importance except how well you do your work.

and

Ayn Rand (The Fountainhead):
Most people build as they live — as a matter of routine and senseless accident. But a few understand that building is a great symbol. We live in our minds, and existence is the attempt to bring that life into physical reality, to state it in gesture and form.

and

Sir Arthur Conan Doyle:
I don't speak for others and they don't speak for me. Mediocrity knows nothing higher than itself; but talent instantly recognizes genius.

and, ultimately

quisling:
stfu & gtfo, n00b.

Thanks for the perceptive response, Cassius.

2010-03-11 Reply Admin

sino:
KP:
The best way to get developers to test the code, either through automated tests, or whitebox/blackbox testing is to have them carry a support/on-call rotation.
As soon as developers know that they are going to get a phone call at 2:30 AM (a time that would usually interrupt their WoW session;-), they will test the code.

I personally don't find unit tests to be very useful or productive to write for release-to-release testing, because you should know what you changed, and what it affected (before you started). Relying on unit tests because you don't identify a change footprint is just band-aiding over a lack of understanding of the workings and machinery of your software. Initial development should be white-box tested and the developer should follow the parameters through the routine and confirm the result, IMHO.

Where unit tests are really beneficial is when you want to test that your application works on other OS's / DB's. For example, it worked in Win XP with SQL 2000, does it work in Win 7 with SQL 2005? Changed compilers? Just run the tests, and you probably have a pretty good idea whether you have problem (assuming that you put the effort into creating tests that target the salient functionality).

It's good to create high-level tests that test functionality. It's tedious and error prone to create a test for every member function of every object (as well as nearly impossible to maintain)
Maintenance programmers and juniors that have no idea what the fuck you had in mind when you wrote what, you arrogant fuck.

Well, let's hope that they can at least form a coherent sentence, and don't just go straight for the baseless ad hominem attack. LOL. BTW more often that not the maintenance programmers are the original developers, and TDD isn't about using the tests as documentation or in place of a specification.

2010-03-11 Reply Admin

KP:
sino:
KP:
The best way to get developers to test the code, either through automated tests, or whitebox/blackbox testing is to have them carry a support/on-call rotation.
As soon as developers know that they are going to get a phone call at 2:30 AM (a time that would usually interrupt their WoW session;-), they will test the code.

I personally don't find unit tests to be very useful or productive to write for release-to-release testing, because you should know what you changed, and what it affected (before you started). Relying on unit tests because you don't identify a change footprint is just band-aiding over a lack of understanding of the workings and machinery of your software. Initial development should be white-box tested and the developer should follow the parameters through the routine and confirm the result, IMHO.

Where unit tests are really beneficial is when you want to test that your application works on other OS's / DB's. For example, it worked in Win XP with SQL 2000, does it work in Win 7 with SQL 2005? Changed compilers? Just run the tests, and you probably have a pretty good idea whether you have problem (assuming that you put the effort into creating tests that target the salient functionality).

It's good to create high-level tests that test functionality. It's tedious and error prone to create a test for every member function of every object (as well as nearly impossible to maintain)
Maintenance programmers and juniors that have no idea what the fuck you had in mind when you wrote what, you arrogant fuck.

Well, let's hope that they can at least form a coherent sentence, and don't just go straight for the baseless ad hominem attack. LOL. BTW more often that not the maintenance programmers are the original developers, and TDD isn't about using the tests as documentation or in place of a specification.

No, not really. In a product shop, that might be the case for a few years, but it is almost never the case in consulting. Even in a product shop, it turns out that the code that actually lasts for decades is the "throwaway utility" you wrote with no concern for design or longevity. By this point, many -- if not all -- of the original developers have moved on or up.

A further common occurrence is for senior developers to hand off completed projects for maintenance to juniors and new hires to crack their teeth on (hopefully) well-designed and mature systems. Based on these real-world scenarios, your argument holds no water; or your perspective is severely limited in scope and duration.

Neither you nor I ever mentioned TDD or formed an argument around it. In your original comment, you were talking about unit tests in general. Dismissed.

As to calling you an arrogant fuck, that is quite simply not an ad hominem. An example of an ad hominem would be: "You're such an arrogant bombastic dumb-fuck that all of your arguments about programming and unit testing are, by extension, tosh."

Additionally, it's certainly not baseless to call you arrogant as such distinction is more than warranted by asinine statements such as:

Relying on unit tests because you don't identify a change footprint is just band-aiding over a lack of understanding of the workings and machinery of your software.

I suspect you have never actually worked on a complex system involving hundreds of components each involving hundreds of their own sub-components or dependencies. Or been short on "white-box" testers due to budget or time constraints. Or integrated multiple legacy systems into a new system. Or come on to a mature project, and jumped right into the middle of it, since you insist you so clearly and instantly understand the inner workings and machinery of "your" software. That's practically the definition of arrogance.

As to my coherence or lack thereof? Sentence fragments often convey style, emotion and content as well or better than any properly sub-claused, punctuated and grammatically correct exposition. Welcome to context, ass-clown. There's a reason American is the most flexible language in the world.

Further still, the terseness afforded by fragments preserves my sanity when I feel compelled to respond to amateur opinions offered as "advice" to unsuspecting but well-intentioned scholars seeking practical tips and best practices on forums such as this; but I can't afford to spend the requisite amount of time to put the author thereof in their proper place.

In short, you're an arrogant fuck.

So am I, but at least I can defend my position.

2010-03-12 Reply Admin

Based on this discussion I'm hiring sino over KP any day.

frits · 2010-03-12 Reply Admin

KP:
BTW more often that not the maintenance programmers are the original developers...

Not true for me. Like any good cowboy coder, I know when to get the hell out of Dodge.

2010-03-12 Reply Admin

In short, you're an arrogant fuck.
So am I, but at least I can defend my position.

Wow, what can anyone say to that.

I might be offended by your comments, except for the fact that they really do speak to your own character, and for that I extend my sympathies to you, but more so to those that must have had the displeasure of working with you.

For someone to get so completely unhinged as you have demonstrated with your own words is really quite remarkable.

Maintenance programmers and juniors that have no idea what the fuck you had in mind when you wrote what, you arrogant fuck.

When I wrote what?

Had your original comment been syntactically parse-able your comments might have stood for something more than just an example of you own insanity.

Congratulations on truly embodying the very spirit of WTF.

2010-03-12 Reply Admin

KP:
In short, you're an arrogant fuck. So am I, but at least I can defend my position.
Wow, what can anyone say to that.
[Blah blah blah, attempt to push conversation into irrational name-calling to avoid the real issue at hand; it works so well in politics:] I might be offended by your comments, except for the fact that they really do speak to your own character, and for that I extend my sympathies to you, but more so to those that must have had the displeasure of working with you.

For someone to get so completely unhinged as you have demonstrated with your own words is really quite remarkable.

My, my. I hope you don't think you're getting out of this with creative quoting, my dear troll.

I was restating as tl;dr the original epithet at which you so noticeably took offense, after a rather lengthy dissection of the faulty premise you originally presented.

Unhinged never came into it.

Please clear your head and re-read my entire reply. You know, the part you conveniently omitted, for lack of retort. I calmly and rationally refuted each of your arguments, the denouement of which was my (now validated) re-assessment of your character based on your frivolous and logically unsound claims. This was the least of my points, but is now quite lulz-ful, given your reaction.

KP:
Maintenance programmers and juniors that have no idea what the fuck you had in mind when you wrote what, you arrogant fuck.
When I wrote what?
Had your original comment been syntactically parse-able your comments might have stood for something more than just an example of you own insanity.

Congratulations on truly embodying the very spirit of WTF.

Really?

Ok, I'll play your little game.

In this sentence, the pronoun what was used to indicate each instance of an unknown quantity and implementation of [a thing that was written by you]. I could have also restructured the sentence thusly: "[The egregious insult and disservice you do to the] Maintenance programmers and juniors [who have to understand and manipulate the code you left them, who] have no idea what the fuck you had in mind when you wrote [each of the various unknown components and pieces of what is surely, as you indicate, a non-trivial system]."

Seriously, I'm mildly concerned by your linguistic inflexibility.

Hope it's not endemic. :D

2010-03-14 Reply Admin

I was a contract test manager on a very old legacy system upgrade project - 30+ developers all over 50, writing Linc code (never heard of it? - neither had I...).

The "IS manager" (in quotes for a reason) had basically employed all his old mates to implement a project so stupid even my mother understood how stupid it actually was.

I tried to implement unit testing for the Devs as the code the testers were getting was beyond abysmal - there was something called unit testing, but it actually just boiled down to 'does the code compile or not'. I explained the benefits ad infinitum, we had workshops, I got in the three .Net guys under 50 to come in and explain the benefits - all for nothing.

Choose your battles, walk away if there's no hope - which I should have done a lot earlier, but you live and learn.

susan2012 · 2010-03-14 Reply Admin

you want to meet the s i n gl es, sex y beauties. ...It takes only a few minutes to submit a profile which, however, will bring you more fun!!!!! Believe me!!!!!!!
...____ S e e k I n t e r r a c i a l [DOT] c o m ___= free to join C'MON NOW!!! ____ S e e k I n t e r r a c i a l [DOT] c o m __

____ S e e k I n t e r r a c i a l [DOT] c o m ___= free to join C'MON NOW!!! :) :) :) :) :) :) :) :) :) :) :) :) :)
:) :) :) :) :) :) :) :) :) :) :) :) :) :)
:) :) :) :) :) :) :) :) :) :) :) :) :) :)
:) :) :) :) :) :) :) :) :) :) :) :) :) :)
:) :) :) :) :) :) :) :) :) :) :) :) :) :)
:) ____ S e e k I n t e r r a c i a l [DOT] c o m ___= free to join C'MON NOW!!!

2010-03-14 Reply Admin

If the comments here are any indicator the state of our profession is grim.

Think of any other professional, whether it be a plumber, architect, or civil engineer. If you come to him or her and ask some difficult task that cannot be done without significantly sacrificing quality, they are going to tell you there is no way in hell they will do it. Because guess who gets blamed when the shit hits the fan.

Yet for some reason many software guys insist on bending over backwards and throwing professionalism out of the window when some scary business guy says "do this".

Blah.

2010-03-14 Reply Admin

Sounds pretty reasonable to me dude.

jess www.online-anonymity.us.tc

2010-03-15 Reply Admin

Hello, I am in second year computer programming and we are just studying unit testing. Can someone tell me what's wrong with this testing?

Thank You.

2010-03-16 Reply Admin

yes, you got what you asked for. that kind of approach never works with that kind of people, and thedailywtf is full of examples. the problem is that somebody failed to see the problem was not the lack of unit testing, but perhaps the education of the devs, or maybe even their motivation. in general, you can't lead intelligent people through: appeal to authority, constraint, candy (aka: bonuses and prizes); you need to convince them, instead. if you fail, and try constraint, for instance, they will screw you (while yielding to your constraints). the wtf is that you didn't see that coming. sorry.

2010-03-16 Reply Admin

To all people posting/quoting novels: Fuck you.

2010-03-17 Reply Admin

A spot of P45 driven development methodology might have helped.

2010-03-17 Reply Admin

untested:
To all people posting/quoting novels: Fuck you.

To untested, with the panties in the bunch: Don't read them.

Now stfu/gtfo.

2010-03-18 Reply Admin

peterbruells:
CoderHero:
Developers should not be tied to bonuses. Developers have a job to do, and that's it. If they don't like doing what they're supposed to, fire them!

Yeah. Bonuses should be restricted to management and get tied o the absolute valute of the gross profit.

All that while developers get stuck with 2% raises and having to put in 50+ hrs/wk so their managers can look good and get bigger bonuses.

2010-03-21 Reply Admin

Actually the Coupling and Cyclomatic complexity code metrics ,are much better when you want to improve code.

2010-03-24 Reply Admin

Anon:
the real wtf fool:
Seems to me that Ian didn't do a good job on selling the benefits to the devs. Making some real examples, showing how certain bugs that got through to test would have been caught...

Exactly this ^. Instead of effectively selling the idea of unit testing he instead went with a passive aggressive system of sending out nag e-mails (to everybody) which only breeds resentment and anger. We have a similar problem with a system for booking time on projects. Rather than sell us on it or, god forbid, make it work in a way that actually reflects what we really do or maybe replace it with a system that doesn't take several seconds just to move from one cell to another, our portfolio manager instead sends out nagging e-mails to everybody naming who hasn't booked their time.

Man, I can smell the evils of Maconomy's web client a mile off.

You want something much more annoying? The desktop client is pretty quick. Our Finance department absolutely cannot see the complaints about Maconomy because they don't use the same unbelievably bad interface as us.

As for the nag e-mails... you wouldn't happen to work at a certain dev shop whereby you would know what I meant if I mentioned mice, would you?

Amusingly the CAPTCHA this time is 'erat'. Rat's aren't mice.

btforsythe · 2010-03-25 Reply Admin

That's nothing. I couldn't tell you how many 'unit tests' I've seen that do nothing more than write something to System.out (not even writing to the appropriate logging system), containing no assertions. At least this developer discovered the assert* method(s).

No project should ever have 300 developers. Has anyone defined a law for diminishing returns in such a situation?

2010-07-21 Reply Admin

I honestly hope am not the only female reader here, or the only female developer who read this and does not find it funny.

Look up 'hostile work environment' and go figure why we are the absolute minorities, by choice. In case you are wondering, one of the many reasons is of course because we are sensitive for your needs, and we do not want to engineer software so well that will put all men out of work ;)

2013-04-25 Reply Admin

That would actually make a slight bit of sense if it had been written (as I suspect the programmer meant to write):

public class StaticDataRequestTest {
@Test
public void startClientReqest() {

    try {
        new StaticDataRequest().onData(null);
        assertEquals(
            " processing client static data request  ",
            true, 
            true);
    } catch (Exception ex) {
        assertEquals(
            " processing client static data request  ",
            true, 
            <b>false</b>);
    }
}

}

At least the theory makes sense, then: Try to do something, catch any errors, and throw an error back with a custom error message so that you'll know where to look. The programmer should still be flogged for the abuse of assert(), but at least it would make a little sense.

BTW, wtf is with all the near-unreadable light colored text? Seriously, cut that out.

Unit Tested

Leave a comment on “Unit Tested”