Slashdot Mirror
Monday, The Death of Websites
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."
And if slashdotting causes more downtime than developer mistakes, couldn't one argue that interesting content is more harmful than bad code for website uptime?
Quack!Quack!.....QUACK!!
This is nothing but unprofessional development - the old "Oh, this is soooo good and sooo simple, how can it possibly cause troub..... ".
/. crew this: while their spelling may be atrocious, their grasp of grammer poor, and their fact and dup checking next to non-existent, they will put major changes to the codebase into Banjo first, then after they've been abused put them into the main /. site.
Any codebase, be it a program, a web site, or a router's firewall rules, should be changed IN TEST FIRST! Then you do your best to break it, and only after you and several others have had at it do you move it to production/HEAD/whatever (and hold your breath).
If you had a wonderful idea over the weekend, GREAT! Implement it in a test branch, try it out, and then move it to production. But if you merge it into the mainline without testing you are not acting professionally.
I will give the
At least, some of the time.
www.eFax.com are spammers
In any properly managed environment, developers don't get to [i]touch[/i] the production environment. If they do, it should be read-only. All changes are made in the dev environment (developers can do what they want), put into test (developers are seriously limited), and then finally into production. Prod should be a physically separate set of servers from dev & test.
If stuff breaks on Mondays, either someone is skipping steps, or there is more going on.
My server
Yes and guess who get to decide what is going to be implemented and when thats going to happen?
Like:
No, Im sure it's a great idea, so just do it. I want it done before 10am.
The tone of the article talks about shoot-from-the-hip developers acting irresponsibly, on impulse. They're taking a recognized and thoughtful practice and painting it as irresponsibility.
Monday is the best time to implement changes to most sites. The irresponsible coder implements on Friday, when errors might not be caught, or fixed, until the next working day, after a full weekend of downtime, bugginess, or insecure behavior.
But that wouldn't make for an interesting story. News flash: updating code often results in bugs that need to be fixed. When do the authors suggest we roll out new versions?
Kevin Fox
Sheesh, next thing you know they'll start spouting nonsense like "burning the midnight oil leads to more bugs."
"Is it fair to say that sysadmins fix things and developers break them?"
Not in my experience. I've seen sysadmins break software by installing security patches, changing server passwords, changing firewall rules, restarting servers at the wrong time, swapping hardware, tinkering with network topology, failing to follow proper startup or shutdown proceedures, failing to perform necessary maintenance, etc. DBAs can cause just as much trouble tinkering with optimization, DB parameters, passwords, etc.
Thing is, anyone involved in the software process in any meaningful way can break it if they do something stupid, and in my experience, stupidity is not a trait confined to a particular profession, culture, religion, or ethnicity but is shared generally by all.