1. Humans shall make no law respecting an establishment of boundaries or prohibiting the free exercise therein, or abridging the freedom of access, or the right to peaceful assembly.
In other words:
The cat is entitled to go outside any time s/he wants.
Winter in Poland is cold - it is -20°C today and the rivers and lakes are frozen over. Hot food helps and was thus consumed. I hope I am wrong, but it appears to me that Polish cuisine consists of cabbage, cabbage, cabbage, potatoes and some meat. And large dill pickles. This is what lunch today suggested in any case: I had 3 different types of cabbage piled high onto my plate - red cabbage, cole-slow and sauerkraut - by a lovely little old lady in the local eatery who thought I lacked essential gasses.
A horse walks into a bar and orders a pint of ale, The barkeeper says: "You're in here quite often, do think you might be an alcoholic?", "I don't think I am", said the horse, and then vanishes out of existence.
You see, the joke is about Descartes' philosophy of "I think, therefore I am, I am, therefore I think", but to explain this before the joke would be putting Descartes before the horse.
Bishop Berkeley espoused the school of thought called Idealism, which went along the lines of: "To be, is to be perceived". One fyne day he dreamt the following conundrum up: "If a tree falls in the forest and no one hears it, does it make a sound?" The implication is that if no one perceives the event, not only does the tree not make a sound, but the tree does not even exist.
This is, of course, a load of old rubbish. The good Bishop can't do me for defamation since he ceased being perceived in 1753. Had he lived in today's more cynical world, he may well have come up with more relevent thought-experiments to illustrate the philosophy of Idealism, thus:
That's nearly 35 years now that I have been in the software production and integration business! As an IT contractor I have witnessed the inner workings of many types of businesses and seen the inside workings of many companies that claim to have a working software development or software integration division.
Way back then, many people got into software because some part of their business had to be automated. The typical accountant sooner or later got tired of doing the monthly book runs on accounting-ruled paper and managed to partially automate it by putting the business transactions in a giant spreadsheet. Over time, the accountant got more sophisticated and used multiple sheets for the spreadsheet, and then had a go at writing the process in - heaven forbid - BASIC, DBASE or CLIPPER. The control of the program development was fiercely protected by the originator and there was a sense of personal ownership of a program that would have been unheard of today. Rolling forward to the present, we now treat such automation artefacts as services that we pay for on a per-use basis, these services are hosted on infinitely-capable computers that are located in places that we do not care where, and the interfaces to these services are very quick, reliable, documented, well-understood and highly secure.
I started off as a bona fide software system developer, but pretty much ended up in the same place: architecting complex business systems using well-defined and trusted services to accomplish the things that had to happen to the data on hand. Along the path of a thousand IT projects, I came across a few superb people, whose intellect and leadership will forever be remembered, and whose fruits of their successful IT projects will serve as a constant reminder of what a successful IT project looks like from day 1 to final delivery. Alas, fate sometimes led me into the clammy paws of a few corporate drones whose heads were not only beset with lard and gristle, but whose selfish, short-sighted, cowardly and meddlesome attitudes spelt all-round disaster for the IT project hand.
Here is how to identify IT project failures in advance, and possibly remove yourself from the equation before it tarnishes you too:
Look out for the verbal clues
As a consultant, I often get brought in at last resort to help "streamline" a project / provide "techincal advice" / assist in the "integration" / etc. The client has never yet said "help us out of a hole", although that is what he should have said. So when I blythely arrive at the first team meeting and hear the project manager say things along the lines of "Panic! Panic! We're all gonna die!", or a little more subtle: "I tell you now, guys, senior management is watching and we are in their firing line, yah?", I know the following:
- The project is already in a huge mess
- The delivery time scales have just doubled
- The project manager is not up to the job of rescuing this mess
- It could be fixed with a series of technical cludges, but the talent is not there
- There will soon be a new project manager. Rinse. Repeat.
I would have had a much better life if I had just walked away every time that this happened.
Buy, don't build, but be careful of the customization
"Can’t we just buy a tool that does X instead of building one?” A Yes-decision to this question is frequently followed by a gazillion lines of customization code to make the bought package do some of the stuff that was not originally included. I have been a player in this silly game more than once and often programs just do not lend themselves to extending because either the data structures or the processes are not well-documented or understood, or the program is simply not meant to be extended. Sure, there are cases for this with an unequivocal "Yes" to this question, especially in our current shift towards distributed service-architectures and an API-driven world. However, if you are not meeting 90% of your requirements straight-up with your chosen third-party product before any customization, this third-party product will extract a price from you by making you do many things that you did not want to do, in order for you to keep your new pet.
The "Not-Invented-Here" vanity fallacy
"They’re charging us X for their tool; why can’t we just build it in-house?” The pointy-haired boss bizarrely then expects the software team to build something akin to Google in six months, including testing, support framework and documentation. It usually transpires that PH-boss is maths-illiterate and just driven by pure personal glory of "having written" a new and essential tool in the business' arsenal of warding off those pesky competitors. And then joins the competition based on the perceived success of said "new tool". Back home, we went back to paying license fees for the old system and felt a whole lot better about doing so.
Testing? Meh! Not 'ere, mate
It is sometimes easy to forget the number of hours that have gone into testing and fixing business software solutions so that they perform adequately well. If you start a new software initiative, you too will also do the same amount of software testing that your competitor had to do and that is mandated by the complexity metric of the work. You can not avoid it to save costs. Whether you choose to do it upfront as part of your software delivery cycle, or choose to test after arriving red-faced at your customer's site and trying to put together a fix and then test it while the customer is breathing down your neck, the choice is entirely yours...
The Silver Bullet Program
In some hill-billy software backwaters there are still folks who believe that one could write a “Silver bullet” program such that one would never need a programmer to program code again, e.g. “programming without programmers”. A pointy-haired boss will frequently try to remind you that you, as a software professional, will soon be out of a job thanks to this impending monstrosity, and that you should therefore take a pay-cut / clean the toilets / babysit his alligator.
On the face of it, it does sound like a plausible idea (no, not the alligator bit), so plausible in fact, that IBM set out in the early 1970's to write such a program called "The Last One". All you had to do is configure it to perform whatever task you had in mind for it. What eventually dawned on those poor IBM software engineers was that the "richer" the capabilities of that program were, the more you had to configure it. In the end, more time and knowledge was required to configure the program than was actually required to write a bespoke program in the first place.
The 100% Bug-free System
In any system of some complexity, there will always be bugs. The best systems have fewer of them, yet they exist...
Any software manager that decrees in a high-pitched voice that they demand a 100% bug-free system needs to go back to Grade 1 in the School of Reality. Recently, I have had to explain to a pointy-haired clone how bugs differ and that non-deterministic bugs, the ones that proverbially happen only in a blue moon and that we had many of, are extremely difficult to track down. This unwelcome news was not well-received.
DevOps and Collaboration tools are for the birds
I have rarely found a situation where DevOps and Collaboration system were overdone: The sensible projects had four or more working environments that were reasonable facsimiles of one another, and with the PRODUCTION and the PRE-PRODUCTION environments being exact replicas of one another, right down to the virtual network configuration. These projects had across-the-board support for development tools, deployments tools, issue managements tools and code repository management. It was beautiful and great software deliveries ensued.
The not-so-sensible projects had a disparate bunch of servers dotted about the estate of various patch levels and software releases, that were given token names like "PROD", "UAT" or "QA". By some for-fetched inference, these servers now declared to constitute IT environments. "QA" inevitably was also the ginger-haired orphan child server that had to act as "DEV" server and the "TEST" server, and for this reason it was not surrounded by other servers with which to do any end-to-end test with. This means that the first time that you do an integration tests is when you deploy to the environment just ahead of your PRODUCTION environment. This is too late in the game to do this sort of test! And when it fails, as many first-time-test do, you need to unwind all this stuff that you installed in there.
Let's save some money with that expensive consultant!
"Let's not onboard this expensive consultant because it will take too much of his expensive time!" Awesome idea. What could have been a neatly prepared document of procedures, contact points, an up-to-date architectural diagram of the IT estate, log-ins to servers and services, and preparing a fully-working and configured workstation for the expensive software consultant in advance, was dragged out to a painful journey of corporate decision-tree discovery stretching across nearly 5 months. Many mishaps occurred, huge amounts of time was wasted chasing tails and rumours to get the bits I need, and stuff simply could not be delivered. As a result of my fastidious research and eviscerating conversations up and down the organizational monkey tree, the few people that were able to help were moved to other departments and given a cease-and-desist instruction to not help me. At the end of the assignment, I still did not have a few essential tools installed on my machine.
Beware ye of Fake Prophets of Y.A.M. (Yet Another Methodology)
If you have ever had to design using the SSADM or the WATERFALL methodology, you are probably old enough to have a few good war stories to tell too. These old approaches are thankfully discredited now and things became better in the last 20 years with the advent of test-driven development and tighter delivery cycles, which is now known as AGILE. It worked fine, and all was good. More recently though, AGILE evolved into a clandestine, religious sect that consists of tribes of AGILE developers/integrators/architects and is led by a grand master, known as THE SCRUM MASTER. The SCRUM MASTER's function is to convene the tribe for regular ceremonies of public humiliation and retribution, and to do future planning for the next round of public humiliations, retributions and further assorted character assassinations. The other function of the esteemed SCRUM MASTER is to save your soul by "removing all your impediments so that yea may do what yea hath comest to do", to quote from the hallowed pages of the Scrum Bibbel, for lo, therein lies IT Project Salvation.
Yet none of it came to pass, and when I raised the issues again about the on-boarding in the beginning of my assignment with my grand old SCRUM MASTER, so that he may "remove my impediments" and thus "prepare the path of the righteous", he told me to "stop whining" and "get on with it". I think this displeased the AGILE gods immensely, since this IT project turned out, all things considered, not a success.
... without destroying the database.
You can do it all in the shell:
- Create a SQL script from the database to drop all the tables
- Execute the SQL script against the database
mysql -u[pwd] -p[user] [dbname] -s -e 'show tables' | sed -e 's/^/drop table /' -e 's/$/;/' > dropalltables.sql
mysql -u[pwd] -p[user] [dbname] < dropalltables.sql
A quick and dirty way of stripping duplicate records out of a MySQL table!, if your table has no indexes or constraints:
Assuming the name of the offending table is customers:
CREATE TABLE customer_dedupe AS SELECT DISTINCT * FROM customers;
RENAME TABLE customers TO customers_dupe;
RENAME TABLE customers_dedupe TO customers;
But what if your original table had indexes?
The task of matching strings between heterogeneous systems, especially that of matching personal or company names or addresses, is not easy with SQL Server's limited set of built-in string SQL functions. Here is a C# CLR-Assembly (with source code) for SQL Server with some advanced string-handling functions that may help:
LTrim - like Oracle's LTRIM function.
InitCap - like Oracle's INITCAP function
FlattenCharSet - Replace western characters with diacritics with best-choice, non-diacritic characters
StripPunctuationMarks - Remove all punctiation marks from the given string.
Page 1 of 2