Guest Post from L.V.
If you want to do the worst possible job at being a Delphi developer, and go from merely weak, to positively devastating, and you want to give your employer the greatest chance of failing completely, making your users hate your product, and going out of business, while exacting the maximum amount of pain and suffering on all around you, if you wish everyone to fear your approaching footsteps, and to be powerless to cross you, here are some startlingly effective worst practices to consider.
Many require very little effort from you, other than occasionally putting your foot down and insisting that certain things are sacred and can't be changed, or that everything is bad and must be changed immediately, no matter what the cost. It is important that the team never sense that they have the collective ability to go around you, and reinstate optimizations that undo your careful work to make things worse. A strict hierarchical authoritarian power structure is key to maintaining steady progress towards pessimization.
No matter how bad things are, you can always find a way to make things a little worse. I can't claim to have invented any of these, and I believe all of these are extremely popular techniques in Delphi shops around the world, and so it seems there is great interest in doing as bad a job as possible. If I can contribute something to the art, it will be in synthesizing all the techniques of all the pessimization masters who have come before.
Now that you have considered whether you want to go there or not, I will share my secrets.
Here is the path that leads to the dark side...
1. Ignore Lots of Exception Types in the Delphi IDE
The more exceptions you ignore, the less aware of your actual runtime behaviors you will be. Encourage other developers to ignore exceptions. Suppress the desire to know what is going on, and become as detached as possible from reality. The optimum practice is to ignore only EAbort and exceptions similar to it, like the Indy disconnect exception. So the pessimum practice is to disable break on exception forever, or to add a very large number of classes to the delphi Exception Ignore. Also make very sure that you ignore access violations.
2. Raise lots of Exceptions, even for things which you didn't need an exception for.
This one is great, because you will annoy all developers and get them to ignore certain exception types. Old code that uses StrToInt that could have used StrToIntDef will eventually make users ignore all manner of exceptions.
3. Try...Ignore
This worst-practice (or anti-pattern) can cause you more grief than any other worst practice:
try
MaybeDoAllOrPartOfSomeThing;
except
end;
To be maximally evil, don't even write a comment. Make every reader guess why you felt that not even logging an exception, and not even trying to restrict your exception handling to a specific sane type of thing to catch and ignore (like EAbort). Make them wonder what kind of evil things lurk below there, and how much memory corruption is being silently hidden. Dare them to remove this kludge of doom that you have imposed.
4. Make your debug builds unable to ever run with Range Checking on, Overflow checking on, even if a developer wants to use it for a while.
While it can be a best practice to ship your release builds with Range Checking, and Overflow Checking off, because the effects to your customer of some relatively benign thing blowing up on them in release, that you can't predict or prevent, it can be a remarkably effective worst practice to build a giant codebase where you don't bother to explicitly turn OFF range checking and overflow checking and I/O checking where it's KNOWN to be generating false positives. In codebases where I can turn on Range Checking and Overflow checking in particular, in my Developer Machine Debug builds, I often find my effectiveness in finding bugs is increased many times. Those who want to pessimize their entire team's work, will want to make using such powerful tools that can be used for good, out of reach.
Note that turning on Range Checking and Overflow checking in Release builds could be a form of pessimization, because it's hard to guarantee that they won't have unknown effects. Most of all, changing these defaults to anything other than what you've always had them at, is injecting a massive amount of chaos, and good developers will often state that this should be avoided in release builds. You might be able to inject this kind of random evil chaos without anyone noticing, if for example, you can arrange for builds to be done on your machine instead of on a build server.
5. Permit Privileged Behavior By Developers with God-Like Egos
Unlike self-organized Agile teams, where rules apply the same to everybody, make at least one person on your team a God Like Developer, who can do things that other developers are not allowed to do. Ugly pointer hackery, and evil kludges are okay, if you're this guy, and totally unacceptable if it's anybody else. To really fully pessimize your team and your codebase, let this guy randomly refactor anything he wants to without asking anybody else's permission. These God-Like developers can review other people's code, but don't need their code reviewed, because they never make mistakes.
6. Don't Document Anything
This is one of the easiest ways to pessimize, it requires basically no effort from you, and all things having to do with software teams and processes, will generally tend to rot on their own. It is consequently one of the most popular ways of pessimization. Sometimes you will need to quote the Agile Manifesto or people will accuse you of having evil motives. Quoting the Agile Manifesto will get these people to shut up.
7. Argue About Indentation
By now things are bad, and significant developer attention will be focused on improving things, undoing your careful work of Pessimization. Instead of letting the team focus on fixing core engineering mistakes and technical debt, redirect the team to consider more carefully the effects of one indentation style over another, and various formatting issues, or comment block styles.
8. Magical Unicorn Build Process, and the Voldemort Build Process
I call these special non-reproducible builds "Magical Unicorn Builds" because it is entirely possible that the one PC where the builds occur is actually the only place in the universe where the code as it lives now on version control actually will build. The secrets and accidents of the entire projects history live as non-annotated non-recorded bits of state on that PC. Contents of the Registry. Contents of various folders that contain component source code that is not kept in source control, and will naturally tend to be slightly different on various machines, and there will be no way to assure that known and controlled set of input data created a traceable end product. Lists of Tools that are required for the product to build will not exist, we don't need no stinking documentation. For bonus Pessimization points, the build should not be done via a build.cmd batch script or a CI tool like FinalBuilder, but should instead require a bunch of Arcane and Undocumented actions performed Manually by the High Priest of the Dark Art of Building the Product. In such a build, we may in fact get all the way to the Voldemort Build. The Voldemort build is a secret known only to one developer, who we will call Voldemort. Voldemort knows arcane and terrible things that would make you weep, which must never be written down, or shared at all. Only Voldemort knows the ultimate price of his own power, and he is willing to take any action to protect his own interests.
If you do all of these things, you may be very near being as bad as it is possible to be, and may become a Dark Lord some day. It will take some hard work, but I'm sure you can do it. Go get 'em, tiger.
Please share your own worst practices in the comment box. Together, we can rule the Galaxy.
If you want to do the worst possible job at being a Delphi developer, and go from merely weak, to positively devastating, and you want to give your employer the greatest chance of failing completely, making your users hate your product, and going out of business, while exacting the maximum amount of pain and suffering on all around you, if you wish everyone to fear your approaching footsteps, and to be powerless to cross you, here are some startlingly effective worst practices to consider.
Many require very little effort from you, other than occasionally putting your foot down and insisting that certain things are sacred and can't be changed, or that everything is bad and must be changed immediately, no matter what the cost. It is important that the team never sense that they have the collective ability to go around you, and reinstate optimizations that undo your careful work to make things worse. A strict hierarchical authoritarian power structure is key to maintaining steady progress towards pessimization.
No matter how bad things are, you can always find a way to make things a little worse. I can't claim to have invented any of these, and I believe all of these are extremely popular techniques in Delphi shops around the world, and so it seems there is great interest in doing as bad a job as possible. If I can contribute something to the art, it will be in synthesizing all the techniques of all the pessimization masters who have come before.
Now that you have considered whether you want to go there or not, I will share my secrets.
Here is the path that leads to the dark side...
1. Ignore Lots of Exception Types in the Delphi IDE
The more exceptions you ignore, the less aware of your actual runtime behaviors you will be. Encourage other developers to ignore exceptions. Suppress the desire to know what is going on, and become as detached as possible from reality. The optimum practice is to ignore only EAbort and exceptions similar to it, like the Indy disconnect exception. So the pessimum practice is to disable break on exception forever, or to add a very large number of classes to the delphi Exception Ignore. Also make very sure that you ignore access violations.
2. Raise lots of Exceptions, even for things which you didn't need an exception for.
This one is great, because you will annoy all developers and get them to ignore certain exception types. Old code that uses StrToInt that could have used StrToIntDef will eventually make users ignore all manner of exceptions.
3. Try...Ignore
This worst-practice (or anti-pattern) can cause you more grief than any other worst practice:
try
MaybeDoAllOrPartOfSomeThing;
except
end;
To be maximally evil, don't even write a comment. Make every reader guess why you felt that not even logging an exception, and not even trying to restrict your exception handling to a specific sane type of thing to catch and ignore (like EAbort). Make them wonder what kind of evil things lurk below there, and how much memory corruption is being silently hidden. Dare them to remove this kludge of doom that you have imposed.
4. Make your debug builds unable to ever run with Range Checking on, Overflow checking on, even if a developer wants to use it for a while.
While it can be a best practice to ship your release builds with Range Checking, and Overflow Checking off, because the effects to your customer of some relatively benign thing blowing up on them in release, that you can't predict or prevent, it can be a remarkably effective worst practice to build a giant codebase where you don't bother to explicitly turn OFF range checking and overflow checking and I/O checking where it's KNOWN to be generating false positives. In codebases where I can turn on Range Checking and Overflow checking in particular, in my Developer Machine Debug builds, I often find my effectiveness in finding bugs is increased many times. Those who want to pessimize their entire team's work, will want to make using such powerful tools that can be used for good, out of reach.
Note that turning on Range Checking and Overflow checking in Release builds could be a form of pessimization, because it's hard to guarantee that they won't have unknown effects. Most of all, changing these defaults to anything other than what you've always had them at, is injecting a massive amount of chaos, and good developers will often state that this should be avoided in release builds. You might be able to inject this kind of random evil chaos without anyone noticing, if for example, you can arrange for builds to be done on your machine instead of on a build server.
5. Permit Privileged Behavior By Developers with God-Like Egos
Unlike self-organized Agile teams, where rules apply the same to everybody, make at least one person on your team a God Like Developer, who can do things that other developers are not allowed to do. Ugly pointer hackery, and evil kludges are okay, if you're this guy, and totally unacceptable if it's anybody else. To really fully pessimize your team and your codebase, let this guy randomly refactor anything he wants to without asking anybody else's permission. These God-Like developers can review other people's code, but don't need their code reviewed, because they never make mistakes.
6. Don't Document Anything
This is one of the easiest ways to pessimize, it requires basically no effort from you, and all things having to do with software teams and processes, will generally tend to rot on their own. It is consequently one of the most popular ways of pessimization. Sometimes you will need to quote the Agile Manifesto or people will accuse you of having evil motives. Quoting the Agile Manifesto will get these people to shut up.
7. Argue About Indentation
By now things are bad, and significant developer attention will be focused on improving things, undoing your careful work of Pessimization. Instead of letting the team focus on fixing core engineering mistakes and technical debt, redirect the team to consider more carefully the effects of one indentation style over another, and various formatting issues, or comment block styles.
8. Magical Unicorn Build Process, and the Voldemort Build Process
I call these special non-reproducible builds "Magical Unicorn Builds" because it is entirely possible that the one PC where the builds occur is actually the only place in the universe where the code as it lives now on version control actually will build. The secrets and accidents of the entire projects history live as non-annotated non-recorded bits of state on that PC. Contents of the Registry. Contents of various folders that contain component source code that is not kept in source control, and will naturally tend to be slightly different on various machines, and there will be no way to assure that known and controlled set of input data created a traceable end product. Lists of Tools that are required for the product to build will not exist, we don't need no stinking documentation. For bonus Pessimization points, the build should not be done via a build.cmd batch script or a CI tool like FinalBuilder, but should instead require a bunch of Arcane and Undocumented actions performed Manually by the High Priest of the Dark Art of Building the Product. In such a build, we may in fact get all the way to the Voldemort Build. The Voldemort build is a secret known only to one developer, who we will call Voldemort. Voldemort knows arcane and terrible things that would make you weep, which must never be written down, or shared at all. Only Voldemort knows the ultimate price of his own power, and he is willing to take any action to protect his own interests.
If you do all of these things, you may be very near being as bad as it is possible to be, and may become a Dark Lord some day. It will take some hard work, but I'm sure you can do it. Go get 'em, tiger.
Please share your own worst practices in the comment box. Together, we can rule the Galaxy.
In the same context....
ReplyDeleteYou should always hard code database connection strings and web service endpoints, as you will never have a server move that you depend on.
You should always put all of your non gui business logic in the onclick event handlers as your UI will never need to change in the future so might as well have them tightly coupled. No big deal that you have to copy and paste that business logic into more than one screen. It's easier than moving it to a common location and having to think about 2 or more places it could be called at once. It's better to have the chance for logic to be different, than to have a shared bug that can be resolved in one place.
Why unit test, you have a end users or if you're lucky a QA team to test, they won't find anything anyway because your code is always perfect because it does not raise any errors due to effective use of empty try/except blocks.
You should never consider using a 3rd party product and that includes open source, because it's better to have all the intellectual knowledge
of your applications code on the team. A developers motto should be always to reinvent the wheel, they can do it better.
You should never use version control, it way more difficult that just using the files system. A developer should only care about the here and now and not worry about backups, history of changes, or ability to work effectively on a team.
Excellent pessimization advice! Thanks for reading along.
Delete