Dissapointed...

[Canrider]

You also had 1760 feet in a mile in your head from somewhere..

It's 5280 feet.

 

[Canrider]

You also had 1760 feet in a mile in your head from somewhere..

It's 5280 feet.

 

[bonj2]

You also had 1760 feet in a mile in your head from somewhere..

It's 5280 feet.

oh yeah shoot, it's 1760 YARDS. so it's actually 1 in 15.
I thought even 1 in 5 sounded a bit dramatic for what it's actually like tbh.

 

[Bug]

Don't you know anything, Chuffy? About a couple of years ago in a past job I was having to write test scripts for a piece of software. This is so that tests can be carried out to make sure the software does what it's supposed to do. How do I, as a mere author of the software, even know what it's supposed to do? Well, that's obvious. Just see what it currently does do, and whatever that is, that's what it's obviously supposed to do.

ROFLMAO!! I was just going through this thread, so sorry for quoting from so far back, but this is classic! I really am a software tester (also been a developer in my distant past) - obviously Bonj isn't or he wouldn't have posted such an inane comment.

How are you supposed to know how to test something, Bonj? The same way that you knew how to write it in the first place. That is that someone took the customer's requirements, which were then turned into a number of (potentially) high and low-level design documents from which you would have written the code. Coming from the design, and linked through to the requirements would have been test conditions and use cases which describe the functional and non-functional aspects of the system to be tested. These test conditions would feed into test cases which would then be implemented by test scripts. As a developer, you would most likely have only performed the unit testing, and as such would have used white-box techniques (boundary value analysis, partitioning, etc) to have performed your testing.

Testing ultimately proves two questions 'have we built the right system' and 'have we built the system right'. Your approach to testing would have done neither and would have just been a complete waste of time. Using the existing code as a test condition is a newbie's mistake and one that no serious software development organisation would let you get away with making.

Sorry if that's boring to everyone else...

 

[bonj2]

ROFLMAO!! I was just going through this thread, so sorry for quoting from so far back, but this is classic! I really am a software tester (also been a developer in my distant past) - obviously Bonj isn't or he wouldn't have posted such an inane comment.

no, i'm not a tester no, but i was made to carry out testing duties in this particular job I once had.

How are you supposed to know how to test something, Bonj? The same way that you knew how to write it in the first place. That is that someone took the customer's requirements

ok, that's assumption number one - that the customer knows what his requirements are, but carry on...

...which were then turned into a number of (potentially) high and low-level design documents from which you would have written the code.

yeah right.

Coming from the design, and linked through to the requirements would have been test conditions and use cases which describe the functional and non-functional aspects of the system to be tested. These test conditions would feed into test cases which would then be implemented by test scripts. As a developer, you would most likely have only performed the unit testing, and as such would have used white-box techniques (boundary value analysis, partitioning, etc) to have performed your testing.

Theoretically, the unit tests should be written first, before the code that passes them. But in this particular company the tests were written so they could say to auditors "we test our software!" and tick a box that earns them ISO9001 accreditation. ISO9001 is a nightmare, I might add, for exactly that sort of reason.

Testing ultimately proves two questions 'have we built the right system' and 'have we built the system right'. Your approach to testing would have done neither and would have just been a complete waste of time.

Tell me about it...
Not really MY approach, I was just the monkey implementing it. It was normally a case of, I'd get told to write tests to cover a huge chunk of the app preferably before the end of the day, so I'd examine each bit, come to the conclusion that "the bloke downstairs that uses it has probably already seen this bit and hasn't bitched about it yet, and it doesn't look wrong, so that's good enough for me" - write a test to make sure it does that. Auditor's box ticked, job done, everybody happy.

Using the existing code as a test condition is a newbie's mistake and one that no serious software development organisation would let you get away with making.

Now now, surely you aren't going to assume you need to tell me why that sort of practice is wrong in principle.

FWIW, they can't have been 'serious' then. Come to think of it, they did at least try and pretend to be 'serious' (unlike the next company after that I worked at that didn't even bother pretending), but I could quite clearly see they didn't do things properly. Getting things 'out the door' was more important, as it is all too often. You might be surprised as to how much of the software in the world that does quite important jobs is written using imperfect methodologies.

If you think it's easy to implement good practice in an organisation that doesn't recognise the value of good practice, and to make them think "wow - so that's what we should be doing! " then I'm afraid I don't envy you.

 

[Bug]

ok, that's assumption number one - that the customer knows what his requirements are, but carry on...

Well, that should be the job of the BAs and Architects. If you can't pin down the requirements then you shouldn't write the software.

I take your point that the real world is often different to best practice. Thankfully, I work for the largest IT services company in the world, and we actually do follow best practice.

 

[bonj2]

Well, that should be the job of the BAs and Architects.

And if there aren't any?

If you can't pin down the requirements then you shouldn't write the software.

And if there's a strong chance management won't like it if you simply sit on your arse with your feet up not writing the software that they've employed you to write?

I take your point that the real world is often different to best practice. Thankfully, I work for the largest IT services company in the world, and we actually do follow best practice.

Good for you. Thankfully now, I also work for a company that does do things pretty well, including testing. Don't bother with any of that sort of poncey shite that never gets anybody anywhere though. We just have productive, open, discussions about what the software's supposed to do rather than sitting around drawing flowcharts and typing pages and pages of crap into MS Project.

 

[skwerl]

I work for the largest IT services company in the world, and we actually do follow best practice.

hmmm...

 

[bonj2]

hmmm...

yeah, come to think of it that sounds like a bit of a contradiction in terms doesn't it. You sure you don't just mean you produce a load of documents?

 

[Disgruntled Goat]

Don't worry about Bonj - he's trying to talk authoritatively about stuff he has no idea about. Again.

1555m in a mile? Sheesh.

 

[jashburnham]

I've not enjoyed a thread so much for a while!

Just a few things I wanted to say:
1. I'd love for this race to happen (i know i know, it's not a race - but it clearly will become one). I confidently predict that Zim will kick Bonj's ass.
2. Bonj, could the fact that you have never experienced frame flex be put down to the fact that you have the leg strength of a 6 year old girl, and therefore cannot produce enough wattage to get over 5mph, let alone cause any part of your bike to flex?
3. Also to Bonj: why not have a read of Sheldon Brown's excellent article on frame material, where he says:

"Any frame will flex around the bottom bracket a bit in response to pedaling loads. This flex can be felt."

http://www.sheldonbrown.com/frame-materials.html

4. I love my new singlespeed; it's the perfect commuting/winter training steed. I'm gonna try going fixed soon...

 

[bonj2]

whatever mate.

Without even seeing the route, zim sensibly accepts that it is likely to be the sort of route that would 'less than ideal' on a fixie and that if he was doing it he'd use a geared bike.


I notice you've got a geared bike jash - it'd be more suited to you than zimzum then. I'd be more than welcome to ride it with you. I'm a gracious loser, and you'd be more than welcome to stop round mine for some tea afterwards.

 

[jashburnham]

Geared and Singlespeed Bonj, best of both worlds and not a silly mtb in sight
Did you have a look at the Sheldon article re flex? Surely you can't argue with the great man himself?

 

[bonj2]

re sheldon - I'm not sure sheldon even IS that great. He's quite great, don't get me wrong, I don't want to get into a sheldon-bashing argument but at the end of the day his main areas of expertise are old and weird bikes, and all the weird and wonderful different measurement systems, metric and imperial, english and french etc. Want to know what tyre size to use on a 1960s tandem trike, and how to express that in any different denomination? Sheldon's your man.
Need a quick step-by-step setup guide for modern, standard, STI shifters? Go whistle.

re. flex: Basically, I'm not denying flex happens - but I've not felt it myself, that's all.
I'm not suggesting people on this forum haven't experienced it, but what I AM suggesting is that people overemphasise and exaggerate it because it seems to be synonymous with being a fast cyclist and 'pushing your bike to its limits' which is something people aspire to be associated with.

 

[bonj2]

re. singlespeed - surely singlespeed is the WORST of both worlds? Ithought the benefit of fixed was that you get 'rhythm' from the momentum of the bike carrying the cranks movikng forward, but the downside is you don't get gears.
Singlespeed doesn't have gears, but neither does it have 'rhythm'.