Slashdot Mirror

A) I did not say a cluster is new. B) You did not have a VAX cluster so much as you had a DEC cluster. C) I have no problem at system-z heads laughing at Linux re-inventing things . Whatever features system-z has -- it (and your DEC cluster) has one key misfeature: vendor lock-in.

Dear Friend,
Your platform license... has expired....
You have 123 Gigabytes of storage in Database49...
To renew your monthly license, please click "Yes to pay", to submit your payment of US $152,042.00 or "No to delete" to remove all of your accounts and data.

Allowing someone else to control all of your information has always been a foolish decision.

That's got to be one hell of an AntiPattern, I guess.

A book that is really missing on this bookshelf is found on http://www.antipatterns.com/, really the definitive guide to learn from others' mistakes. O well, not always only others.

You should check out the anti-patterns book:

http://www.antipatterns.com/

Has good tips (I think) on analyzing and categorizing the problems, and then strategies for dealing with them. Some of it might be obvious, but it is so reassuring to read about the same problems you are seeing with some practical advice on what to do next - I found it both therapeutic and entertaining.

Looks like you have lots of spaghetti code, and a poltergeist thrown in for good measure. I'll bet some cut and paste code in there also.

Good luck!

In my view, the basic goals of CM are: (a) know what you shipped, (b) know when you shipped it, (c) deliver releases on time as predicted, (d) have product functionality decisions actually under the control of product management, and (e) drive product functionality from actual customer requirements.

Set out like that, it seems blatantly obvious that that's the way things should be, but when you start trying to make things work that way you'll find that the required changes to working practices are controversial.

Lots of developers will hate you. Developers like to be able to go fix any problem they happen to notice without telling anyone, and they hate documenting things. They don't test adequately enough to even ensure that their fixes work, far less prevent regressions. (Yes, that's gross generalizing and unfair to many, but I'm also a developer.)

The QA and documentation teams will love you, for exactly the same reasons.

If the current situation is a mess, which it probably is if they're desperate enough to offer the job to someone with no experience, it'll take at least a year to straighten it out.

In fact, before accepting the position, make sure it isn't a Poison Chalice Project.

Expect massive political battles, flamewars, perhaps even sabotage by primadonna developers.

Make friends with other clueful people who've worked on CM and process improvements. Run ideas past them, discuss problems with them, and so on. They don't necessarily have to be people at the same company.

Reading suggestions I haven't seen anyone else mention yet: "AntiPatterns",
"The Rational Unified Process".

Also, bear in mind that if you manage to fix things, and development suddenly start shipping reasonably bug-free releases on time, you are unlikely to get any of the credit. The prima donna programmers and project managers will get the glory.

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

I don't have my copy of Anti-Patterns with me, but quoting from memory, the Lava Flow anti-pattern states something along the lines of:-

The more legacy code in an application, the greater the chance that the people responsible for the code are no longer involved in the development of new code. This leads to an inability to change the legacy code, mainly based on fear of undocumented effects of the changes. As the amount of "untouchable" legacy code increases, the diffuculty in making new changes increases until the point when the Lava Flow cools sufficiently into an immovable solid mass that becomes basically unmodifiable without major low-level re-writes.

You absolutely need the book on Design Patterns by Gamma et al.

Also you should check out the Antipatterns book by Brown et al. A book on "common pitfalls" and more importantly, possible resolutions.

But, if you want to deviate a bit from the technical books, and if you want to expand your understanding of design and design patterns in software, and the philosophy behind it, you might be interested in Christopher Alexander's books and writings. His books are quite old, published in the 70s.

He's an architect (of actual buildings), but his ideas apply to anything that is designed. He developed the concept of "design patterns" and the computer science world has been applying his ideas. Here is a little article about him. It's because of him that we have the following definition of pattern: a solution (set of forms or rules), which solves a problem (resolves a set of forces), in a given context (a recurring sitution). A very general idea.

Basically he was trying to come up what he calls a "Pattern Language", a high-level way to describe design patterns in urban architecture, so that people could basically design their own homes and buildings. But the end result was something more profound and philosophical. Very interesting stuff but rather touchy-feely at times. For instance when he talks about the QWAN (quality without a name, the mystical sort of "beauty" that a good design has).

He also has (or he's still working on, I'm not sure) a recent multi-volume work called "The Nature of Order". I want to read it and I bet it's a much more interesting and insightful book than Wolfram's recent giant tome about a "new kind of science", and without the hype.

Disclaimer: I'm just getting into this type of stuff so I'm not 100% aware of all the history, etc., but Alexander's the name I see everywhere.

If you're interested in antipatterns, check out (of course) http://www.antipatterns.com/.

Nobody ever got fired for buying IBM

Nobody ever got fired for buying Oracle

And this is a Good Thing. I've got nothing against relational databases where they have their uses; but in the past ten years every application has been converted to requiring a relational database. I personally know of several cases where the data - which used to be managed on an old PDP-11 or the original IBM PC in under a megabyte of disk space - has been migrated to Oracle, at enormous cost and expense. Things that used to be simple (e.g. a list of a few hundred customers) now require a team of Oracle database experts and extensive optimization just to keep up with the same performance that was achieved on twenty-year-old hardware without Oracle.

There's even an official designation for a misused and missaplied technology like this: Golden Hammer.

This is the classic stovepipe system anti-pattern, and is caused when your code has too many intertwined and circular dependencies. When this happens, it's impossible to even predict how many areas will be affected by a given change. The code has reached the point of no return. (Note the original intent of object-oriented programmed is to reduce dependencies between varying systems.)

Of course, what most companies do that this point is hire a Mongolian Horde of programmers to fix things by brute-force, aka the "Warm Bodies" anti-pattern. By then, it's too late. Leave.

Unfortunately, as a junior developer, you probably shouldn't be making these decisions yourself; you'll only anger people above you. If there isn't a culture of refactoring when necessary, there's nothing that can be done. It must either always be there, or brought in and bought in from the top. Sadly, most PHBs do not understand this. I find it laughable when a PHB will hire 40 people for 4 years gang-banging the code, instead of having 3 or 4 smart people send a year refactoring.

By Jimminy and by the Force, Taco's problem is in the AntiPatterns. He is suffering under the Spaghetti Code AntiPattern.

By Jimminy and by the Force, Taco's problem is in the AntiPatterns. He is suffering under the Spaghetti Code AntiPattern.

Frankly, in a world where almost all of the cheap hardware is x86 commodity components, the allure of NetBSD (emphasizing portability to esoteric platforms) isn't really compelling