Modern Programming is Rubbish

[andrewducker]

Today's conclusive proving that one of Andy's theories is right:

Events make debugging much, much harder.

When your code reads:
Do A
Do B
Do C

it's easy to follow the chain of logic and see where The Bad Thing is happening.

When your code reads:

DoEvent Something

and then events can hook into it from _anywhere_, it means stepping through the code until you find the place where it all goes wrong, usually in a piece of code miles from everything else, and written in a way that worked fine until last week, when you fixed something else - but didn't know to update this bit of code as well, as it wesn't clear it was there!

Comments

[cloverbee.livejournal.com]

I ran across a paper that you might find interesting that breaks code down into an equation of reliability. The equation isn't 100% finished and is being done by Perdue U. It breaks down realiability by looking at rigidity and complexity. Rigidity is defined by the simplicity (I won't describe how they define that - you can read it yourself) but complexity is done by what you are describing. Looking at the number of calls in and out of each program and complexity (variables, complex data types, arrays, cursors, etc) within the code. I will send you the link later.

[odheirre.livejournal.com]

I may be reading your comment wrong, but I disagree. Or, I disagree with what I think you're saying.

If you have a "DoEvent Something", that Something shouldn't need to do anything that is necessary for the object to continue to work.

Ideally, that Something shouldn't be able to break the object. Otherwise, you can throw the error so it's easy to debug, or make a best-guess scenario and continue.

Part of the issue is there's complexity in the situation (you have to build an object with step A, B, C, and D, but you can't define exactly what's going to happen in step B until the object gets used, and step B may change based on the business requirements/client/program). You can either hardcode step B for each situation, or extend B as an event and let the consuming programmer decide what step B is going to, well, be.

[surliminal.livejournal.com]

Ideally, that Something shouldn't be able to break the object. Otherwise, you can throw the error so it's easy to debug, or make a best-guess scenario and continue.

It's not that it creates an error - it's that it changed the state of the system, and tracking down that state-change takes longer because without stepping through the code you have no idea what instructions are going to take place at that point.

[azalemeth.livejournal.com]

My bugshooting usually involves just stepping the thing over though a nice, fat, debugger, to work out where it dies, and then having fun with breakpoints.


...Yes, I'm obviously not a commercial programmer :P.

[andrewducker]

There's another way to do debugging? It's either that or sprinkling the code with some kind of logging...

[code-delphi.livejournal.com]

Threading really, really makes it hard... many people just can't seem to get their head around it. I've been building multi-threaded servers for many years, and I still occasionally get bitten by threading bugs. They provoke the nasty, obscure happen-once-a-week or so kind of crash that is effectively impossible to reproduce.

My strategy for testing involves building "floggers", a number of client apps that basically hit the server as hard as it can, causing all those threads to be busily churning away. It's the best way to shake out any lingering bugs (or so one can hope). I've yet to come across a way to do it through any kind of review or analysis!

Of course, the advice I give the younger guys can be summed up as "keep it simple", and that absolutely applies to using threads. Use as few as you can get away with, and keep it single-threaded if you possibly can.