Part of a collection of travelogues by Trevor Hopkins.

I wrote the material below many years ago, when I was engaged in supporting a new IBM software product (which I have anonymised below). This product is, of course, long since discontinued but, on re-reading, I find it captures some of the frustrations found when using software development tools which are less than perfect!

You'll probably spot that I was a little steamed up when I wrote this. Things really are better now (mostly!).

Profile of a Project X Developer

Project X (PX) is a new development at the leading edge of technology, so it is only reasonable to expect that, for developers using this toolset, certain personal characteristics would be more highly desired than others. Based on the recent class, here's my profile for the ideal PX developer, and hints to make him/her even more perfect:


The main PX tools are unreliable, and liable to collapse without warning. Expect catastrophe at every step. When using PX, you should save (click the button) after every major change or addition (i.e. every two minutes). The class catchphrase is "save early, safe often". We mean it.

Take backups, before even the most trivial change to your model or application configuration. Take backups of your backups, on a different machine, in case you have to install PX, DCE, DB2, or even NT from the metal up. Never, ever, overwrite one backup with another backup - use those gigabytes of store you've spent all that money on.

Always check you have got DCE tokens, before you even consider the possibility of thinking about starting the System Management GUI. Never, ever forget this, otherwise your paranoia will be fully justified - and we'll be trying out your backup recovery procedures.

Never, ever, attempt to de-install (remove) a server once configured. This is guaranteed to destroy your server installation - everyone remember how to revert to the original installed state? Just keep adding new servers, or changing the existing servers; after all, you've got lots of core and rotating storage to keep those DLLs in, right?

Expect code generation bugs. As soon as you depart from the prepared script (i.e. try anything which has not been pushed right the way through by an expert), the emitted code will not compile. This is true even if you do not add any user-written 'business logic'. Hint: don't even try to add business logic, until you've got everything else absolutely perfect.

Cultivate a photographic, 100%-reliable memory. One stupid mistake or omission can set you back a half-day's work. Never, ever, make mistakes - they cannot easily be reversed. Remember: "mistake = potential restore from backup".


You must understand the minutiae of everything to do with PX, everywhere. Think at least twice, slowly and carefully, before pressing any button on any GUI.

Check everything, twice. Understand completely the code-level structures which OB is generating; make sure all of the mapping and relationship structures are exactly right. Ensure you have a complete comprehension of the PX Object framework classes.

In PX, run through every single SmartGuide, stopping and thinking carefully about every single page. Consider the implications for the generated code structures. Never, ever, guess: if you get it wrong, you can spend ages trying to track down the problem, not to mention waiting for the recompile process to complete.

Go home, come back in the morning, check it again. You've considered all the runtime performance implications of the decisions you've made, yes? All right, you're probably ready to generate and build something. You're sure it's OK?...

Write down everything you did. Keep a complete log - paper or electronic, doesn't matter. You'll need to remember in detail what you did, so that you stand a chance of doing it again.

The PX programming models are transparent. Several OHP foils and speakers from the class talked about the object models being 'transparent' - this is true; you can see right through all of the interfaces to the underlying structures and semantics - persistence/caching mechanisms, transactions/sessions, etc. You cannot afford to write either server-side business logic or client-side code without fully understanding the precise semantics, and performance characteristics, of the generated methods you are using. Interface specifications are never sufficient to allow for server-side changes without potentially affecting client code.

(I suspect the speakers probably wanted to say 'opaque' - i.e. you cannot see the grubby details. But it was transparently obvious that they meant 'transparent'!)

Use Rational/Rose. Build your models in a modelling tool. Remember, the import is a one-shot: check, and check again, in RR before clicking that little button... Are you sure that you have every single attribute, relationship, cardinality correct? Those relationships really are the correct way around, right? - you can't very easily change them later. And remember to check absolutely everything in all of the SmartGuides after import, to work around some of the code generation bugs.

Understand Murphy's Law: If anything can go wrong, it will. Make sure it cannot possibly go wrong. Check, monitor, think carefully before every step. You'll not be surprised to learn that the main AIX server in use by the PX support team is

Use the defect reporting mechanism. Once you've cracked the (paranoid!) security stuff, this is easy. Include every possible piece of information you can - they really do have to reproduce the situation exactly to fix the problem. Remember: you're not wasting your time - bugs fixed now will make all of our lives easier in the future. And, anyway, you've got lots of time to wait while that install process or build job grinds on....

Ignore inheritance and polymorphism. This doesn't work in any useful way. Transform your truly object-oriented design to a form which removes all interface inheritance (i.e. remove all polymorphic behaviour) and replace it with specialised case analysis in your business logic. Flatten all your implementation inheritance, duplicating attributes and business logic methods as appropriate. Make sure you keep track of all that duplicated code. But, remember, PX is object-oriented, right?

Remember: relationships don't inherit properly; queries don't correctly use inheritance in non-trivial cases, making a polymorphic findByPrimaryKeyString() (with a specialised home) is too much like hard work. Implementation inheritance can be made to work, but is badly supported by PX, and usually gives you code generation errors. Wait for V2.0...

Your development process must be top-down, one-shot. (This used to be called 'waterfall'.) You must have a very complete, and documented, analysis and detailed design before you even take PX out of the box. You must forget everything you ever learnt when using tools like VisualAge - you cannot afford to try and make extensive design changes once you've started using PX. And don't forget the end-to-end analysis - making performance-tuning design changes will take you forever. With PX, it must be "right first time".

Understand everything else on the machines: DCE, NT, DB2, MKS tools, Rational/Rose, C++, Java, VisualAge, IDL, CORBA, ... Lots of stuff to keep you anoraks (trans. for US residents: geeks) busy.


All of the PX tools are just desperately slow; cultivating a hobby, such as knitting or browsing the Web, is recommended. The runtime's not much better - you must understand the performance limitations inherent in the PX architecture.

The interactive response of PX is astonishingly bad, considering the power and size of the hardware in use. Worse still, the response is highly variable, presumably because of Java's garbage-collection. Anyone who thinks that Java is a language ready for large-scale implementations should be forced to sit in front of PX for an afternoon.

The build process takes forever; expect 100Kbyte or more of makefiles. Expect tens of minutes to elapse while nmake does its stuff. Do not ever make coding errors; your life will end (or maybe it will just seem like it) before you get to fix all of the compiler-detected errors. And, you can't even do anything else while the compile proceeds - it eats all available CPU cycles. Demand a newer, bigger, faster machine for your PX builds, and keep the old one for some real work. Or, get multiple processors in the box. Go on - get your hardware upgrade right now...

The initial server activation delay. I don't even want to talk about this. Remember to get your configuration exactly right first time; 'verify' does no such thing - your configuration can still be broken - and probably is, unless you've checked it very, very carefully.

Understand the bandwidth limitations implicit in using remote objects. Architect your solution so that it can tolerate extensive delays. Threads, everywhere, in your clients. Remember you won't get more than a few thousand ORB transitions per second (total - for all clients). If you have non-trivial logic on the client (not recommended), then consider hand-crafting local (client) copies of objects. No object replication from server to client in PX, right? And the Event service is even worse - think twice before architecting a solution which demands more than a 100 or so events per second across an ORB.

Keep your object models small, with lots of attributes in each object. Design your relational DB schema the same way. Remember, traversal across relationships is very expensive - even when you use foreign keys. (Dynamic SQL, hop at a time,...) If you must perform extensive navigation, use 'raw' SQL: write those joins explicitly, and get your results back in a table. And remember, PX is object-oriented, right?