Monday, The Death of Websites 207
An anonymous reader writes "Developers implementing 'weekend inspiration' are more dangerous than hackers.
Vnunet.com has this article about how eager developers and administrators create more troubles than hackers and viruses do for websites. How about those of us who start the week with a cup of coffee and the morning online-news? My inspiration and new ideas for development are definitely not the cause of the Monday-crash hour ... I think."
Weekend Update (Score:4, Informative)
They talk as if the developer has an idea over the weekend, then comes in Monday morning and implements this idea without any testing. But if that were true, the websites would crash Tuesday. I mean, really, how many of you think these guys are really making the changes Monday morning and the websites are thus breaking Monday morning? Any changes you see Monday morning were loaded over the weekend, and are probably the result of all last-week's work. Whatever ideas anyone got over the weekend will be coded and tested this week and installed next weekend; they won't show up until next Monday at the earliest.
QA (Score:5, Informative)
We have an 8 people tech team now (manager, programmers, support, QA). Whereas before we programmers would just use a development environment somewhat similar to the production (live) environment, test it a bit, deploy at will and monitor if anything went wrong, things have progressed a lot. Now we develop on a development environment as close to the production one as possible, then this is released to a test environment (also as close as possible to the production one) to be tested by QA, and that is finally released on the production (live) environment after it all tests ok (including regression testing).
Moreover, all the code changes are now under CVS, and we have automatic tools for monitoring the site, emailing errors, etc. QA is also done by separate people. IMHO it is conceptually flawed to allow the developers to do the final testing, by definition. (Though of course this is not always possible for cost reasons, it should be a goal).
The quality of our site is much better now. Problems almost always only arise when people want to bypass QA or force things through for emergencies.
IMHO, what is needed is:
1. Professionalism by the developers.
2. Testing, testing, and testing -- by the developers.
3. QA, QA and QA -- by someone other than the developers!
4. Managers must know the test/ QA process should never by bypassed -- this unfortunately is probably the hardest point.
I taught a couple of ecommerce classes for MBA students and had them actually do hands on development (in a limited sense of course) so they could get an appreciation of this process. Hopefully if some of them are managers they will remember that and not try to shortcut the due process.
Re:Developers shouldn't be able to break stuff (Score:5, Informative)
But they (we) always do.
Speaking purely from my experience, half the problem is managers who don't understand that "I've finished coding" does not mean "I am ready to deploy."
It's been years since I got time to do serious "pre-deployment" testing. The code deadlines are so tight...well, you can imagine.
In school they always talked about post-production/predeployment. I've never worked in a place where that was anything but a dream. I've watched people edit LIVE CODE before, I mean the ACTUAL pages, while they're up! Used to be, compile time was so long, people exhaustively checked their code before trying to compile it. Now we compile to check for typos. Guess this is similar sloppiness.
Just my 2 cents worth.
Re:Great sample:) (Score:2, Informative)
I've been working on a project for the last two months, and when they created our 'live' date- they picked today.
Moving the site from test, to live, we noticed 5 or 6 small problems (due to browser cache issues, people still had parts of the old pages).
So- I guess that Monday morning we had issues, but not due to the developer (me) I hope- due to the arbitrary date set by people in charge.
Re:Great sample:) (Score:4, Informative)
1,000 respondents give a +/-3 percent 95% confidence interval.
Rule of thumb - worst case is if the population is split 50-50. This gives a base 95% confidence interval of 1. Divide by the square root of n. That is your worst-case confidence interval.
If you can make a random sample of all major websites (define major websites), then no need for stratified sampling - only if you wish to talk about specific subgroups or if sampling the general population is difficult is stratified sampling necessary.
Re:Developers shouldn't be able to break stuff (Score:4, Informative)
In the project that I'm working on, this is done. And it's the main reason that changes to the "live" web sites are usually disasters.
I develop something new, test it very thoroughly on my test machines. It all seems to be working, so I hand it over to the guys running the live systems. They install it in different directories than I did (and won't ever tell me where they plan to installl things, so I can't defend against this very well). They change the cgi scripts' search paths so they can't find some of the things they need (or find old versions). They install images in random new directories without changing the tags.
Then they complain that my stuff doesn't work, and was obviously not tested thoroughly.
Well, of course it wasn't. I have no way of knowing how it'll be mangled when its installed in the live systems. I can't find out the directory structures of the live systems. But I get the blame when it's installed all wrong.