From Tom LaRock’s latest idea…
For a change I’m not going to mention performance (well, not more than once anyway) and I’m not going to preach backups or recoverability. Nor am I going to talk about technical issues like many others are doing.
Instead I’m going to briefly mention several (well, 9) problems that I’ve seen a lot in last year or so. These certainly aren’t specific to databases, but I’ve been seeing them with regards to databases, so…
Poor/missing development environment
A development environment that’s months out of date with production, has different databases from production (eg has databases that in the production environment are on different servers) will cause problems. Either code will never work in dev (eg missing linked servers) and hence can’t be properly tested or works fine in dev and fails in production.
Either way, the appropriate response from the senior architect when told that the development environment is months out of date is not "Well, yes. I could have told you that. So what?"
Lax security
When everyone, from developers to help desk to business analysis has full sysadmin access, things are going to go wrong, sooner or later. Probably sooner. From new databases that no one knows anything about, to missing databases, altered settings that break backups or other maintenance, code changes that ‘no one’ made, missing data, etc.
This kind of setup is a bloody pain to fix; without strong support from management it’s near-impossible to fix. Far better to start correctly if possible
Lack of change control
There must be some control over what changes are made, by who, to what and when. Developers should not be just deploying their changes whenever they feel like it with no regard to what other people are doing, whether the system is in use or not, or who is inconvenienced.
Likewise there needs to be some record of what was done, when and why. If no one knows what is being done then when something breaks (and it’s when, not if) there will be no way to tell where to start looking.
No testing/UAT environment
A testing environment should, as close as possible, mimic production. Down to the size of the databases and volume of data. Where possible it should also use load-generating tools to emulate production load.
This should be the environment where the business owner tests to ensure that the change/project does indeed do what they want, it should be where the test cases are run and checked (but not where unit tests are run). This is also the environment where performance testing should be done, if it’s not done in a development environment that contains data volumes representative of production.
No documentation
It often seems that all managers want documentation, but none will allow time for doing said documentation.
Relying on other developers’ knowledge of how a particular system works is foolish at the best of times. When there’s frequent turnover in the development staff, it’s downright idiotic.
At the very least there should be high-level documentation on how the system works, what it uses, how it interacts with other systems, what dependencies it has
Poor specifications
A detailed specification for a project anticipated to take 2 months cannot (once all the boilerplate text is removed) be a page long.
A vague specification just means that the developer will either have to spend significant time with the business owner, or will develop something that doesn’t come close to what was actually intended.
Poor impact analysis
A change is deployed (at some random time, whenever the developer feels, no change control remember) and 3 unrelated applications promptly break spectacularly, and maybe a fourth breaks but no one notices for a couple of days.
Impact analysis is not a waste of time, no more than design is (see next point) and the worse the documentation is, the longer and harder the impact analysis will be.
Long and hard that it may be, it’s far better than trying to fix bugs/failed applications after a deployment to production.
Lack of design time
"We don’t have time to design, just get coding." Far too common a statement generally from managers that don’t understand the software development process. Design is necessary, time spent in design is time saved later in the development process. Skimping on the design is not going to save time, it’s going to cost time later in the project.
And no, Agile does not mean ‘No design’, it means not doing massive up-front design but doing smaller amounts as necessary.
Exaggeration of skills
Claiming to be a database architect or business analyst or system architect does not make a person one. Skills are required, they don’t just magically appear when the title is bestowed.
If you claim to be a database architect, you had better be able to design databases, understand normalisation, appropriate data types, etc. ‘It’s cool’ is not a good reason to use a data type where it just doesn’t fit.
Oh, and business analysts, architects and developers are partners in the development process. Being a business analyst or architect doesn’t make someone better than the developers, nor does it mean they know more about software development than the developers do, especially if they have no development background.
Gail sounds mad!
8-I