The Daily WTF: Curious Perversions in Information Technology

Katja Bergman · 2005-04-12 Reply Admin

dubwai:
Don't take this the wrong way but are you currently in school? I just want to understand your perspective on this. Again, just so you understand my perspective (I'm not trying to boast or anything (I wish I could)) I've been developing and maintaining software for more than 6 years.

Yes, I'm still in school. But most of my experience is based on my dad who works as a freelance software developer and who'se doing a pretty good job at it too. Before I started following computer science classes, I'd be learning from my dad and his work. I'm into programming ever since I was about 11 years old. And today I'm pretty good at it too. [:D]
However, my point of view is of course that of a freelance developer in this case. This means a lack of good resources, always a deadline close-by, never enough time to do things real proper and lots of talks with customers who want you to create something and they want it finished yesterday... For my dad, this sometimes means working real, real hard for one or two weeks after which he's earned enough to relax for another month at some beach in Southern France or so. Not that he's doing that. He just continues to work even more, but still, it's the idea that counts.

dubwai:
Maintainability is not a 'nice to have'. It's a necessity. Without it, each software cycle takes longer and longer until the team is constantly putting out fires and each enhancement takes as long as the initial development, if not longer. This is where I find myself now thanks to my esteemed predeccesors.

It depends. Sure, for a software cycle it is good to have something that can easily be maintained. But if you build a product and it's finished once you're done with it, there just aren't any more cycles. It's finished! Done. Game over. And there are already plenty of products that have been finished already, but companies just want to get more revenue out of them so they just add newer cycles and try to sell something old as something new.
Take a look at MS Office, for example. Everyone is using it, and most companies just continue the latest versions of it. And why? To type standard letters that could have been written with a Word version of 5 years ago. There's just no need for all those new features. Then again, MS just continues to make "newer" versions of Office so people will continue to buy newer versions. They don't need it but for some reason, they think they need it...
For my dad, things are very simple. He gets an order from a customer to build a special product. He starts working on it, finishes it, provides the customer the finished product and perhaps the source if the customer pays extra and then he gets paid. End of job. Nothing to maintain, no new cycles. Just libraries that might be re-used for the next project.

Not all projects are big projects that need to be maintained forever...

dubwai:
In short, yes, sometimes you have to drop the philisophical purism and get the job done. I don't buy into all the OO purist ideas on a good day. But I know a bad design when I see one (having maintained many and created a few) and this kind of thing is a bad design. Just because time constraints forced a bad design doesn't make it a good design.

If you can describe a senario where the getCannonicalSelf approach is the only way to solve a problem I might be more open to this being an acceptable approach.

There's never an "only way" to solve something. It's just that some solutions save a bit of time while the proper way would be preferred but more time-consuming. This is especially important when you're stuck in some project and need to get around some problem that you don't know a solution for. You just work around it and try to keep it working. Someone else might know the proper solution but he's not working on it, is he?

Still, a bad design is better than no design. It means a bad pay, of course but still... No pay is worse.

loneprogrammer · 2005-04-12 Reply Admin

dubwai:
Maintainability is not a 'nice to have'. It's a necessity. Without it, each software cycle takes longer and longer until the team is constantly putting out fires and each enhancement takes as long as the initial development, if not longer. This is where I find myself now thanks to my esteemed predeccesors.

I must agree with this. I'd guess 90% of software out there is in the maintainance phase. And it's probably more.

Katja Bergman · 2005-04-12 Reply Admin

loneprogrammer:
dubwai:
Maintainability is not a 'nice to have'. It's a necessity. Without it, each software cycle takes longer and longer until the team is constantly putting out fires and each enhancement takes as long as the initial development, if not longer. This is where I find myself now thanks to my esteemed predeccesors.

I must agree with this. I'd guess 90% of software out there is in the maintainance phase. And it's probably more.

And as I said, for big projects this is true. But some projects are just finished once they have been written, tested and people start to use them.
It just depends on what you're trying to build. My dad works a lot on projects where data needs to be converted from one format to another. Mostly non-XML data and sometimes nasty binary data. Once you've created such a convertor, however, it is finished. Maybe a bugfix or two afterwards but it can be used for decades afterwards without requiring any new cycles.

Not all projects need to be maintained afterwards. And for plenty of projects, maintenance is so rare, it doesn't justify the additional time wasted on it during the initial start-up.

If it ain't broke, don't fix it.
That's a philosophy that's practiced by many companies. And basically, if the current cycle of your project works fine, you don't need a new cycle...

dubwai · 2005-04-12 Reply Admin

Katja Bergman:

It depends. Sure, for a software cycle it is good to have something that can easily be maintained. But if you build a product and it's finished once you're done with it, there just aren't any more cycles. It's finished! Done. Game over. And there are already plenty of products that have been finished already, but companies just want to get more revenue out of them so they just add newer cycles and try to sell something old as something new.

Most software is not off-shelf. Most software is developed for a mission critical business functions. The end of life for these products is rarely after they are initially written. The guy across from me is maintaining COBOL programs.

Katja Bergman:

For my dad, things are very simple. He gets an order from a customer to build a special product. He starts working on it, finishes it, provides the customer the finished product and perhaps the source if the customer pays extra and then he gets paid. End of job. Nothing to maintain, no new cycles. Just libraries that might be re-used for the next project.

Not all projects are big projects that need to be maintained forever...

What your Dad is doing is the exception. If you are talking about trivial single person throa away applications, then sure you can do pretty much what you want. But if the approach in this thread is for extensiblity and the code isn't going to be enhanced or maintained, what exactly is the point? The approach in this thread will make thing more difficult than 'normal' OO, not less.

dubwai · 2005-04-12 Reply Admin

Katja Bergman:

Not all projects need to be maintained afterwards. And for plenty of projects, maintenance is so rare, it doesn't justify the additional time wasted on it during the initial start-up.

If it ain't broke, don't fix it.
That's a philosophy that's practiced by many companies. And basically, if the current cycle of your project works fine, you don't need a new cycle...

To add to what I said above: then why introduce complications like the getSelf() method? There's nothing you can do with this that can't be be accomplished with proper OO technique. And there's no OO program that can't be written procedurally. So why use a bastardized OO-esque hack?

dubwai · 2005-04-12 Reply Admin

Katja Bergman:
This is especially important when you're stuck in some project and need to get around some problem that you don't know a solution for. You just work around it and try to keep it working. Someone else might know the proper solution but he's not working on it, is he?

So, you would then agree that no other country besides Britian and Iraq should criticize how the US is handling the war in Iraq because the other countries aren't fighting the war, right?

[;)]

The point is again that ingnorance of the 'correct' solution doesn't make a bad design good.

Katja Bergman · 2005-04-12 Reply Admin

dubwai:
Most software is not off-shelf. Most software is developed for a mission critical business functions. The end of life for these products is rarely after they are initially written. The guy across from me is maintaining COBOL programs.

True. Yet for all software there's one simple rule. You write it, compile it, test it and when it works okay, you don't need to adjust it anymore. It could happen that additional features are requested, of course. But in those cases you just start the whole cycle from the beginning again.
There are many companies who develop software in-house. For them, maintenance is indeed important. Other companies will just out-source their project to someone outside the company and if you're hired ny such a company, you're never sure if they will continue to pay you for any future maintenance. With outsourced projects, the project often tends to have a last cycle.

dubwai:
What your Dad is doing is the exception. If you are talking about trivial single person throa away applications, then sure you can do pretty much what you want. But if the approach in this thread is for extensiblity and the code isn't going to be enhanced or maintained, what exactly is the point? The approach in this thread will make thing more difficult than 'normal' OO, not less.

Throw away applications? Not really. My dad recently got a call from a customer from 10 years ago, asking for a 32-bits version of a tool he had written back then for Windows 3.11. They're willing to pay handsomely so he's considering this option.

And that's just it. The next maintenance cycle could be next week but it could also take several years before the development team can start on the next cycle. And in all that time, a lot can change. New techniques, new developers, new systems. Sometimes, especially with medium or small projects, it's easier to start from scratch than to try and maintain an existing system. And if a project has been built by creating lots of smaller modules, maintenance would never be too hard to begin with. It's the very basic principle from before OO development, which is called modular development. Too many people are forgetting about keeping their projects modular simply because they assume that OO would be enough to keep it easy to maintain.

Katja Bergman · 2005-04-12 Reply Admin

dubwai:
The point is again that ingnorance of the 'correct' solution doesn't make a bad design good.

I'm not saying that. All I'm saying that a bad solution is still better than having no polution. Example...
Say, a very poisonous snake bites you in your hand. The poison is lethal within minutes and you know that. You could choose to put some rope around your arm and prevent the poison streaming into the rest of your body. You could opt for sucking out the poison hoping that it will work. But you know the poison kills within minutes and all you have is this large axe, a hot fire and a friend who knows how to use both for a quick surgical procedure.
Chopping off the hand still puts you in danger but at least you got rid of the problem of the poisoning. It buys you some time with a bit more security. Sure, you could spend your last minutes searching for a rope or something else to tie off your hand, but the clock is ticking and the stakes are high. Not making the deadline could be a very unpleasant experience...

And again, bad designs are still better than no designs... In the end, only the result counts, not how you did it.

Charles Nadolski · 2005-04-12 Reply Admin

Anonymous:
Alex Papadimoulis:
public class DocumentBO 
Where is it that teaches programmers to name their objects "Foo Business Object"?

Maybe it's just me, but it seems redudant to name my objects "object".

Maybe he meant BO == Body Odor?

MySpamFiles · 2005-04-12 Reply Admin

I just joined to dis this Katja Bergman person...

It was just today that we discouvered her at work... and seeing her 'background' there has been much discussion if she's real or some poor geek posing as a naturalist-lesbian-programmer-with-a-kitch-site (sic!)...

My bet is that she's fake :)

What about it Katja ?

dubwai · 2005-04-12 Reply Admin

Katja Bergman:
True. Yet for all software there's one simple rule. You write it, compile it, test it and when it works okay, you don't need to adjust it anymore. It could happen that additional features are requested, of course. But in those cases you just start the whole cycle from the beginning again.
There are many companies who develop software in-house. For them, maintenance is indeed important. Other companies will just out-source their project to someone outside the company and if you're hired ny such a company, you're never sure if they will continue to pay you for any future maintenance. With outsourced projects, the project often tends to have a last cycle.

You've just explained why outsourcing software is a nightmare. My company does this and all the outsourced projects are falling down, impossible to maintain and costing the company a lot of money. We are going through contractors like water. I think we are even considering suing one. I used to work for a consulting firm that lost a 500 million dollar lawsuit on a 11 million dollar project. If companies were smart, they would demand maintainable code from contractors. Eventually they will wise up.

Essentially you are saying that if you are just on a contract position you might as well deliver shit because you won't have to deal with it. Personally, I think that is unethical. Think if your plumber or electrician or painter or even your doctor thought this way. Would you go back for repeat business?

Katja Bergman:

And that's just it. The next maintenance cycle could be next week but it could also take several years before the development team can start on the next cycle. And in all that time, a lot can change. New techniques, new developers, new systems. Sometimes, especially with medium or small projects, it's easier to start from scratch than to try and maintain an existing system. And if a project has been built by creating lots of smaller modules, maintenance would never be too hard to begin with. It's the very basic principle from before OO development, which is called modular development. Too many people are forgetting about keeping their projects modular simply because they assume that OO would be enough to keep it easy to maintain.

Modularity is the core principle of OO. A project without modularity is not really OO. The code is this thread is not modular. Any developer who uses this class must know when to call getSelf() and when to just use the Object reference.

dubwai · 2005-04-12 Reply Admin

Katja Bergman:
Chopping off the hand still puts you in danger but at least you got rid of the problem of the poisoning. It buys you some time with a bit more security. Sure, you could spend your last minutes searching for a rope or something else to tie off your hand, but the clock is ticking and the stakes are high. Not making the deadline could be a very unpleasant experience...

Actually in software, a bad design is sometimes worse than no design at all. What if the snake turns out to not be poisonous? There are two snakes in North America that look very similar. One is poisonous and the other is not.

Abraham Lincoln was likely killed not by the bullet wound but by the doctors trying to remove the bullet that was safely trapped in scar tissue. They had a plan.

In any event, what you are describing is flailing. It doesn't bear any resemblence to a good product.

dubwai · 2005-04-12 Reply Admin

MySpamFiles:
I just joined to dis this Katja Bergman person...

It was just today that we discouvered her at work... and seeing her 'background' there has been much discussion if she's real or some poor geek posing as a naturalist-lesbian-programmer-with-a-kitch-site (sic!)...

My bet is that she's fake :)

What about it Katja ?

This is just rude. Sorry but I don't think this called for.

b1xml2 · 2005-04-12 Reply Admin

I cannot disagree more with Katja. As a senior developer, I have seen enough sloppy work done that I will shake my fists at anyone who asserts any of the following:

There is no need to test code, just writing the code is good enough.
There is no need to worry about maintenance, just getting the software out is good enough.

Whether it be a free-lance consultant, a contractor or a salaried employee, it is important to remember this:
1. Write reasonable good code within budgetary constraints and time limits.
2. Leave the attitude that if it ain't broken don't fix it to the sales personnel. Any self-respecting developer will look out for improvement in both coding, architecture and modelling.

>>
Still, a bad design is better than no design. It means a bad pay, of course but still... No pay is worse.
<<

A bad design is simply bad design, no more, no less. It is not better than nothing. In fact not having a design is better than a bad design. Why? Because you don't end up LYING. The bas design promises to do something but ends up doing something else altogether. Now that is unethical and unacceptable. Plus, you not only not get paid, you get sued and end up with a bad reputation and the consequences: No one wants to hire you.

2005-04-12 Reply Admin

Looks like code-generator output; I can't imagine a real person purposefully writing all that cruft. This code is in some serious need of refactoring; all those accessors are a bad smell...

b1xml2 · 2005-04-12 Reply Admin

I think I know why the developer wrote it the way he/she did:

The developer wanted to demonstrate the ability to write OO programmes. Hence, the <object>.<object>.<object> which is reflected by
>>

  <font>this</font>.getSelf().setDescription( 
      <font>this</font>.getSelf().getConstants().getForwardHeader
      + <font>this</font>.getSelf().getDescription());

<<

The only problem is that in trying to prove something, the developer has to quote George Bush slowly but surely proved quite the opposite: inane programming.

Katja · 2005-04-12 Reply Admin

b1xml2:
I cannot disagree more with Katja. As a senior developer, I have seen enough sloppy work done that I will shake my fists at anyone who asserts any of the following:

1. There is no need to test code, just writing the code is good enough.
2. There is no need to worry about maintenance, just getting the software out is good enough.

I'm not saying that code should not be tested. Of course it should be tested before it's used for production. And it needs to be tested very well. It's just that outsourcing companies and freelance developers have to work in a different way than inhouse developers. In general, a freelancer writes the code, compiles it, tests it and then it's given to the customer for further testing and evaluations. The real problem, however, is when customers receive this very urgent product and just don't test it themselves. It could happen that a customer returns after 18 months or so saying they recently started testing your product and found a few bugs. Sorry, but customers who respond that late will just have to pay again for those bugs to be fixed. (This actually happens once for my dad. They did pay him to fix it too.)

Also, you don't need to have to lie about a bad design either. At least you have something that can be used until something better is available. Say, your leg gets amputated. You could ride in a wheelchair or walk on crutches until a new artificial leg is available. Or would you have to sit on the floor until that artificial leg is ready? I myself prefer to ride at least, or walk with crutches.

The same with software. A customer is in need for a solution. A freelance consultant offers his services but starts off with a bad design. He apologises for the inconvenience and offers the client several options. Either a total refund and no solution, or a partial refund and a not-so-good product that still works okay. (Because, as I've said: the design is bad but it behaves as it should.) Many customers will choose the second option because it just means they have at least something useful.

Any project that a consultant delivers should at least do the things that were promised. The client must be able to use it. Design flaws can be bad but the whole project might still work as expected, in which case the bad design isn't that bad. It the project does what it's expected to do, then does it really matter that there's a bad design behind it?

Technically, all bugs in software are just the results of bad design.

Charles Nadolski · 2005-04-12 Reply Admin

b1xml2:

In fact not having a design is better than a bad design.

Quite true on this point, because you end up with a potential re-rewrite if the design sucks. Let's take an example from my work... A very long time ago in a galaxy far away, somebody needed a way to interface with multiple kinda of databases (SQL, MySQL, Oracle) through a single program to build queries and whatnot. In order for this to be implemented quickly, classes were added in a horizontal fashion instead of being implemented in a hierarchical structure. Fast forward a couple years, when a new program was written that also needed to work with multiple databases, and another, etc. The database query class was copy and pasted between projects and small modifications were made. Then you come to today when we realized we needed a single DLL so that we wouldn't have conflicting versions, and if small changes would be made, it would be easier to just link to an updated DLL.

Well, several problems:

1) Exporting one class (let alone several classes not arranged in a particlar hierarchy) to a DLL is a pain in the ass
2) The existing code structure in the individual projects (beyond including the DLL) could not be modified (hence, the classes couldn't be re-organized into a better hierarchy)
3) The DLL had to be able to to be wrapped in .NET in the future
4) Somehow, the library had to be written to perform ten times faster because it had poor performance to begin with.

So, we're stuck. Either we re-write with the knowledge that we break our existing software, or we spend countless man-hours untangling a proverbial Gordian's Knot.

dubwai · 2005-04-12 Reply Admin

Katja:

Any project that a consultant delivers should at least do the things that were promised. The client must be able to use it. Design flaws can be bad but the whole project might still work as expected, in which case the bad design isn't that bad. It the project does what it's expected to do, then does it really matter that there's a bad design behind it?

Let's say I hire a electrical contractor to do some wiring in my house. He comes in, wires up everything with aluminum wire, installs breakers that allow too much current and neglects to ground the outlets.

Everything works fine. I can plug in my appliances and I am good to go. Then one night the cheap wiring job starts a fire and burns down my house.

But it worked, right?

Katja:

Technically, all bugs in software are just the results of bad design.

Gots-ta disagree with that too. Most bugs are the result of programmer error. The design is rarely the cause but when it is, it's nasty to fix.

Katja · 2005-04-12 Reply Admin

dubwai:
Let's say I hire a electrical contractor to do some wiring in my house. He comes in, wires up everything with aluminum wire, installs breakers that allow too much current and neglects to ground the outlets.
Everything works fine. I can plug in my appliances and I am good to go. Then one night the cheap wiring job starts a fire and burns down my house.

But it worked, right?

Now, you don't understand what I am saying here. Look at the original code as it is posted here. It is a bad design but will work just as well as any better design. It might be slightly slower than the better design version because it has a few more function calls but technically, it has no bugs. Bad designed, yes. Bug-ridden? Nope.

Okay, comparing to that electrical contractor... What am I saying? I don't know anything about electronic wires! I already have problems plugging in the cables in my computer. [:)] But okay, for comparison, assume cheap wire that performs just as well as the more expensive one. No fires, no shocking effects, it just works as expected. The only difference you'll notice is in the electricity bill because it's now 2% higher than it would be if you'd used the more expensive one...

Compare it more to the use of gasoline, diesel or LPG engine in your car. Depending the shape and weight of your car, your driving style and the distance you have to drive, one of these engines will perform better than the other two. One of them will be the better design than the other two. But they would all bring you to where you want to go.

I wonder if you can even call it a bad design if it still does what is expected...

dubwai · 2005-04-12 Reply Admin

Katja:

Okay, comparing to that electrical contractor... What am I saying? I don't know anything about electronic wires! I already have problems plugging in the cables in my computer. [:)] But okay, for comparison, assume cheap wire that performs just as well as the more expensive one. No fires, no shocking effects, it just works as expected. The only difference you'll notice is in the electricity bill because it's now 2% higher than it would be if you'd used the more expensive one...

Compare it more to the use of gasoline, diesel or LPG engine in your car. Depending the shape and weight of your car, your driving style and the distance you have to drive, one of these engines will perform better than the other two. One of them will be the better design than the other two. But they would all bring you to where you want to go.

I wonder if you can even call it a bad design if it still does what is expected...

If I buy a car that costs an extraordinarily large amount of money to maintain or is unreliable compared to other cars with similar functionality, I call that a badly designed car. Even if it gets me around town.

dubwai · 2005-04-12 Reply Admin

Katja:

Okay, comparing to that electrical contractor... What am I saying? I don't know anything about electronic wires! I already have problems plugging in the cables in my computer. [:)] But okay, for comparison, assume cheap wire that performs just as well as the more expensive one. No fires, no shocking effects, it just works as expected. The only difference you'll notice is in the electricity bill because it's now 2% higher than it would be if you'd used the more expensive one...

For future reference, cheap wire isn't going to make a noticeable effect on energy use. It's just going to be less safe.

jstrayer · 2005-04-12 Reply Admin

Katja Bergman:
Not all projects are big projects that need to be maintained forever...

Maybe, but mine are (not big, but running forever).

If you go here (http://www.radianresearch.com/catalog/703bltn.pdf) and look at page three of the PDF you'll see a couple of screens from some software I wrote back in '93. It still being maintained.

Some software that is used at my current job is at release number 20.2 (that's year 20, second quarter).

Xepol · 2005-04-12 Reply Admin

Ack. Gurgle. Brain melting. BAD CODE!! BAD CODE!!!

this.sucks().getAClue();

b1xml2 · 2005-04-12 Reply Admin

I cannot disagree more with Katja,

>>
Technically, all bugs in software are just the results of bad design.
<<

I cannot avoid saying that such statements come from inexperience or lack of it whichever is the case. I am sorry but that's the real truth.

There is a distinct difference between modelling, architecture and programming. All bugs are not the result of bad design. Just as all illnesses are not viral. It is one thing to express one's opinions and everyone is entitled to it. However, making sweeping statements without qualification will inevitably bring down the wrath of the Gods upon Ye! So beware ! <GRIN>

>>
Any project that a consultant delivers should at least do the things that were promised. The client must be able to use it. Design flaws can be bad but the whole project might still work as expected, in which case the bad design isn't that bad. It the project does what it's expected to do, then does it really matter that there's a bad design behind it?
<<

Interesting. And when the client wants the extension work done, he'll then discover a $5000 two-week project will cost him another $20,000 and two months because the design was crappy. Does he go with it, or re-commission with a view of saving money in the long term?

There are issues of ethics here and with the dot com bust, we lost a lot of wannabes. We may well need to shed more wannabes, clear the decks to keep faith with the good people.

Think about it.

2005-04-13 Reply Admin

dubwai:
Anonymous:
Too bad he missed the _self private member. That way he could assign _self = this; getSelf() { return _self; }. Which would just be more fun.

:|

No no no. getSelf() should call the protected method getRealSelf() which calls _self.getSelf().getRealSelf().getSelf()._self

The word 'Self' looks funny capitalized.

Should have read "The word 'Self' looks funny capitalized, by itSelf."

2005-04-13 Reply Admin

The real WTF in this code is of course the fact that getSelf() should have been called getThis() as to not be confusing!!!

Seriously though, I suppose that experience from some particular language, with its "self" convention must have been there at the background.

This guy just has missed what this is, or rather, what his object already is.

I shudder to think of the programming made by such people.

ammoQ · 2005-04-13 Reply Admin

Many software products live much longer than the programmers would expect; and change requests are likely in any stage of the livecycle. For that reason, every program that is not a "fast shoot" to solve a one-time task, should be as easy to maintain as possible; otherwise, it becomes a time bomb.

dubwai · 2005-04-13 Reply Admin

ammoQ:
Many software products live much longer than the programmers would expect; and change requests are likely in any stage of the livecycle. For that reason, every program that is not a "fast shoot" to solve a one-time task, should be as easy to maintain as possible; otherwise, it becomes a time bomb.

True true.

Every time I've ever seen a manager tell a developer to just code it real fast and don't worry about making it clean, the manager was wrong. The code ended up being a millstone around our necks.

Buff · 2005-04-13 Reply Admin

Yep, I find it's less hassle persuading the customer that I need the time to do it properly than it is dealing with the aftermath if I don't..

Customers have a very short memory, and always forget that you told them you that if they wanted it done fast, it would cost them later.

2005-04-14 Reply Admin

public class DocumentBO {
public DocumentBO getSelf(int recursionLimit) {
 if(recursionLimit <= 0) {
 return this;
 }
 else {
 return this.getSelf(recursionLimit - 1);
 }
}
}

PS this captcha shite is ILLEGIBLE!!!! hint: you can't read purple letters on a purple background, because there needs to be a difference in color between background and foreground, wouldn't you agree?

Alex Papadimoulis · 2005-04-14 Reply Admin

Anonymous:

PS this captcha shite is ILLEGIBLE!!!! hint: you can't read purple letters on a purple background, because there needs to be a difference in color between background and foreground, wouldn't you agree?

You could always register, ya know ;-).

I do agree, sometimes it's completely illegible. But it is required to stop the spam, which wascoming in at 10-20/day.

drjava · 2005-04-15 Reply Admin

No. this.this doesn't exist.

DWalker · 2005-04-17 Reply Admin

Someone mentioned doing a search for "this" to learn about it. On Google at least, a search for "this" doesn't return anything useful about "this" subject.

2005-04-18 Reply Admin

I think comments like 'If it does what it is supposed to, can it even be called bad design?' clearly displays a lack of experience in development of large commercial systems. Most large scale systems are (or at least should be) developed in stages, and I am not talking about the usage of an iterative development methodology but rather that most large scale systems are comissioned and built with the intention of the functionality being extended / augmented after the initial deployment.

If a large corporation needs a new system, or needs to replace an existing system and the overall timeline to achieve the 'vision' of the effort is, let's say two years, you surely do not want to get into a situation where the first production devliverable takes place two years later. If you structure your project that way you are almost certainly doomed to fail. Instead the project will be broken down into smaller pieces with the most critical functionality being developed and delivered first and subsequent pieces being added on in later stages.

If the first deliverable does exactly what it is supposed to feature wise but the underlying design is so crappy that adding on subsequent features means an increase of 2X in terms of effort then the design is indeed that, crappy.

A good design should keep extensibility and maintainability in mind.

If you are developing utility programs or smaller single purpose applications, this need is not as apparent and perhaps the consequences not as costly. But on larger projects the importance is paramount.

2005-04-18 Reply Admin

Anonymous:
I think comments like 'If it does what it is supposed to, can it even be called bad design?' clearly displays a lack of experience in development of large commercial systems. Most large scale systems are (or at least should be) developed in stages, and I am not talking about the usage of an iterative development methodology but rather that most large scale systems are comissioned and built with the intention of the functionality being extended / augmented after the initial deployment.

If a large corporation needs a new system, or needs to replace an existing system and the overall timeline to achieve the 'vision' of the effort is, let's say two years, you surely do not want to get into a situation where the first production devliverable takes place two years later. If you structure your project that way you are almost certainly doomed to fail. Instead the project will be broken down into smaller pieces with the most critical functionality being developed and delivered first and subsequent pieces being added on in later stages.

If the first deliverable does exactly what it is supposed to feature wise but the underlying design is so crappy that adding on subsequent features means an increase of 2X in terms of effort then the design is indeed that, crappy.

A good design should keep extensibility and maintainability in mind.

If you are developing utility programs or smaller single purpose applications, this need is not as apparent and perhaps the consequences not as costly. But on larger projects the importance is paramount.

In this case the person making the quoted comments admits she is a student and her father who is a professional programmer specializes in writing protocol parsers. In both cases bad design doesn't come back to haunt you too much. Student projects tend to be short one offs that you never go back to. Parsers between legacy systems are also small and tend not to require a lot of maintaince... this assumes the design of any new stuff that needs the parser to get old data is not so screwed up that you have to make major changes to the parser to talk to different versions of your current system.

Stan Rogers · 2005-04-19 Reply Admin

dubwai:
Katja:

Okay, comparing to that electrical contractor... What am I saying? I don't know anything about electronic wires! I already have problems plugging in the cables in my computer. [:)] But okay, for comparison, assume cheap wire that performs just as well as the more expensive one. No fires, no shocking effects, it just works as expected. The only difference you'll notice is in the electricity bill because it's now 2% higher than it would be if you'd used the more expensive one...

For future reference, cheap wire isn't going to make a noticeable effect on energy use. It's just going to be less safe.

I take it that electricity is not your forte. While that may be true of purely resistive systems, reactive systems have a nasty habit of consuming the same amount of power within a range of applied potentials. In order to do that, they need to draw greater current at lower potentials, such as those occasioned by voltage drops due to resistance in power supply conductors and reactivity between power supply conductors. Thus, poor supply cabling can in fact increase the total consumption of power in a reactive system without generating enough extra heat to become unsafe.

dubwai · 2005-04-19 Reply Admin

Stan Rogers:

I take it that electricity is not your forte. While that may be true of purely resistive systems, reactive systems have a nasty habit of consuming the same amount of power within a range of applied potentials. In order to do that, they need to draw greater current at lower potentials, such as those occasioned by voltage drops due to resistance in power supply conductors and reactivity between power supply conductors. Thus, poor supply cabling can in fact increase the total consumption of power in a reactive system without generating enough extra heat to become unsafe.

And all of this applies to home wiring?

dubwai · 2005-04-19 Reply Admin

Stan Rogers:

I take it that electricity is not your forte.

P.S. I take it that being a prick is your forte.

Stan Rogers · 2005-04-20 Reply Admin

Yes, it does apply to home wiring. Reactive loads include things like electrical motors (furnace, refridgerator, air conditioning, many portable appliances), as well as some of the guts of electronic appliances. Didn't mean to come off sounding like a prick, but was responding to a reply to Katja given in much the same tone.

dubwai · 2005-04-20 Reply Admin

Stan Rogers:
Didn't mean to come off sounding like a prick, but was responding to a reply to Katja given in much the same tone.

You're wrong about my tone. Look at some of my other posts in this thread. And I'm going to call you on your bullshit. You definitely meant to be a prick.

Katja, feel free to buy cheap wiring. It's perfectly safe according to Stan.

Stan Rogers · 2005-04-21 Reply Admin

dubwai:
Stan Rogers:
Didn't mean to come off sounding like a prick, but was responding to a reply to Katja given in much the same tone.

You're wrong about my tone. Look at some of my other posts in this thread. And I'm going to call you on your bullshit. You definitely meant to be a prick.

Katja, feel free to buy cheap wiring. It's perfectly safe according to Stan.

I didn't say anywhere that buying 22 gauge corroded stranded wiring insulated with cellophane and sold at the local discount store would definitely a safe choice. Rather, I said that it is possible for wiring to be safe (in other words, it would pass UL standards, etc., be considered safe from a marketing & liability standpoint, can be labeled and sold as such legally, and so forth), while providing just enough drop in potential over an installed run length to cause an increase in overall power consumption (in reactive loads) when compared to purer copper cables with properly-controlled crystal structures manufactured by a company that allows QA errors only towards oversizing diameter. The difference at the jobber's or retailers will be reflected in the price.

You made a definitive statement in my area of expertise that was patently false, and the "for future reference" clause is a patronising put-down in anyone's book. Programming, for me, is an "accident" of engineering endeavours. In electricity and electronics.

dubwai · 2005-04-21 Reply Admin

Stan Rogers:

You made a definitive statement in my area of expertise that was patently false, and the "for future reference" clause is a patronising put-down in anyone's book.

Apparently, interpreing what people write is not your forte. "For future reference" is not a put-down. I don't know what planet you are on but what I meant was: "Katja, in case you, in the future, need to make a decision about what home wiring to purchase, go with the good stuff.. It's worth it." When I put someone down, you'll know.

Stan Rogers:
Programming, for me, is an "accident" of engineering endeavours. In electricity and electronics.

So, what you are saying is that besides any work experience, you really have no qualifications to be a programmer.

Stan Rogers · 2005-04-25 Reply Admin

Well, besides the time spent at learning and practicing algoriths (which are germaine to far more than programming), actual gate-level logic, higher-level Boolean algebra and propositional calculus, register design, machine coding (not that wimpy assembler stuff), physical interfacing and so forth, I'm completely bereft of a foundation in computer sciences. I'm qualified to teach CS, and have taught a course or two in my time, but I've never actually taken it, no.

And if the wee poll I've taken around the place is any indication, "for future reference" seems to have exactly the same connotations for others around here as it had for me. If it wasn't intended that way, perhaps we can blame it on regional differences. Lord knows that's not completely unheard of.

dubwai · 2005-04-28 Reply Admin

Stan Rogers:
Well, besides the time spent at learning and practicing algoriths (which are germaine to far more than programming), actual gate-level logic, higher-level Boolean algebra and propositional calculus, register design, machine coding (not that wimpy assembler stuff), physical interfacing and so forth, I'm completely bereft of a foundation in computer sciences..

I've done all of that in my time as a Phyics major and/or in getting my degree in Computer Science. Most of them (e.g. gate-level logic, register design) have very little use in high-level programming. Knowing how how to manufacture rebar doesn't make one an architect.

Stan Rogers:
I'm qualified to teach CS, and have taught a course or two in my time, but I've never actually taken it, no.

Qualified how?

dubwai · 2005-04-28 Reply Admin

Stan Rogers:

And if the wee poll I've taken around the place is any indication, "for future reference" seems to have exactly the same connotations for others around here as it had for me.

My small informal poll tells me that is a hyper-sensitive response to a perfectly neutral statement.

Blue · 2005-04-29 Reply Admin

My REALLY small informal poll says that that phrase can be taken either way - it is possible to say it in both sarcastic and sincere ways - since there is no tone of voice (or bracketed indicators) in the text, it is purely up to the reader how they choose to interpret it - however they only have a %50 chance of correctly guessing what the author meant.

-blue

Niels · 2005-05-04 Reply Admin

Katja Bergman:

And as I said, for big projects this is true. But some projects are just finished once they have been written, tested and people start to use them.

And then they bring in 'users' ;)

'Unfortunately', I've never participated in a projects where there weren't atleast multiple iterations of testing, adjusting and rewriting involved. As soon as the software is atleast stable, people start asking for more options, and sales starts pressing you to implement these because they sell better then bugfixes, let alone refactoring :)

Regarding the case you present: a 'converter' that converts from one data format to another is just not really comparable to a large projects. I've done a couple of these (most often because it would take less time to write a converter than have the customer send a proper SQL dump instead of the 'bad' one that was uploaded), but they are rather straightforward input-output thingies that can't really go 'wrong' in a lot of places. Most projects in software companies are of the kind that do require updates and maintanance. And since coders tend to leave for better jobs, you tend to have to maintain code that's not written by you.

foxyshadis · 2005-05-06 Reply Admin

dubwai:

If I buy a car that costs an extraordinarily large amount of money to maintain or is unreliable compared to other cars with similar functionality, I call that a badly designed car. Even if it gets me around town.

Or you could just call it a Jaguar. But I'm a simple fox. (=p)

Of course that wouldn't even get you around town half the time...

2007-08-31 Reply Admin

Javier Lozano:
Or maybe he/she just learned the wonders of abstaction? You know, factories that create factories that create factories...[:P] I love this part: public void addNonPersistentDocumentBO(DocumentBO doc) { Documents.add(doc.getSelf()); }

Maybe they wanted to make sure not to add a null pointer to the list? doc.getSelf() throws an exception if doc is null.

Reinvent This

Leave a comment on “Reinvent This”