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."
Great sample:) (Score:5, Insightful)
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?
Not just Programmers (Score:5, Insightful)
The article suggests that developers come back from their weekends and start fiddling with websites, but I think this last paragraph is perhaps equally or more accurate. Managers get "inspired" over the weekend just as much as code writers.
Unprofessional development (Score:5, Insightful)
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.
Developers shouldn't be able to break stuff (Score:5, Insightful)
If stuff breaks on Mondays, either someone is skipping steps, or there is more going on.
Re:Not just Programmers (Score:5, Insightful)
Like:
No, Im sure it's a great idea, so just do it. I want it done before 10am.
Am I crazy? (Score:3, Insightful)
It's better than Friday, stupid. (Score:5, Insightful)
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?
Sounds about right (Score:2, Insightful)
Re:Unprofessional development (Score:4, Insightful)
Inspiration and discipline.. both needed (Score:5, Insightful)
First of all, presumably it is a good thing that people think, and get inspiration. Mon-Fri 9-5 is not the best time for thinking - this is the time for meeting deadlines, sitting in meetings, answering the phone, putting out fires, and so on. The only time most of us have to actually sit and think is the weekend. Personally, I think that should be encouraged.
The next step is implmenting what you have dreamt up. Obviously, most ideas fail - ask any patent officer. And obviulsly, implmenting a new idea without checking with colleagues, drawing it 0ut in a spec, getting that spec approved, then protoyping, testing, tuning is not ideal either. These procedures were invented for good reasons - not just to constrain the creative mind. This is where most developers fail - not in coming up with ideas, but in being disiplined in implmenting them. I hear "we cannot plan ahead, it does not work like that for us" all the time from my developers - this is always a misconception, and seems to me simply a combination of inexperience, laziness and inability... nothing that cannot be fixed!
Michael
What's next? Late night overtime produces bugs? (Score:5, Insightful)
ebay motors- example (Score:1, Insightful)
Re:The cause of bugs (Score:2, Insightful)
He does have a valid point about testing before putting code into production and being able to roll back changes. That's all pretty obvious stuff.
The mention of managers pressuring for changes, but not allowing for adequate testing time is also typical.
-Craig.
ohh come on.. (Score:5, Insightful)
Re:What is it about developers? (Score:5, Insightful)
Well, first of all those are all pretty big changes. No developer worth a damn would try to do something that massive over a weekend, by himself. Also in general I think there is more possibility of a small change causing big problems in development work than IT work, although this certainly does happen with IT, as I can attest to, having spent many a late night struggling with some sever setup or what have you.
Is it fair to say that sysadmins fix things and developers break them? What is different about a software engineer's brain than a systems engineers? Talk amongst yourselves
Again I think it comes back to the job of a developer, not being harder per se, but perhaps being
Re:What is it about developers? (Score:5, Insightful)
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.
My "weekend inspirations".. (Score:4, Insightful)
Stupid article (Score:5, Insightful)
And generally business websites don't see as much traffic on the weekends, so naturally the weekend is the time to make changes.
So wow, it's no shock that Mondays are when you're most likely to see problems with a website. But these problems and hiccups are the price you pay for progress.
If you don't want to chance any disruption in your life, then I guess you should never change. Otherwise, get over it.
Need 4 environments Dev, UAT, IT & prod (Score:5, Insightful)
They need a Dev environment. And THAT's ALL they touch. They deliver their code to UAT.
QA needs 2 environments:
- Unit Acceptence testing (UAT) and all bugs go back to Dev
- Integration Testing (IT) and all bugs back to Dev or you need SysAdmins who need to hack the OS middleware &| environment)
Production where NOHING is allowed until its gone through UAT & IT.
Re:QA (Score:3, Insightful)
Of course it is. If the code breaks, it's the developer's fault, even if the Manager broke the process. The Manager can FORCE it to be the developer's fault, so what reason does the manager ever have to accept blame?
When you have a choice between waiting 3 days for a fix that has to be done TODAY, and risking breaking something that absolutely MUST NOT BE BROKEN, it is your fault, as a developer, for the manager having to make that choice at all, and either way they go, you will take the blame for the negative impact of their choice.
It's called slavery. Get used to it.
Re:I would fire the IT staff (Score:4, Insightful)
Oh, but you don't do anything interesting on it.
Have you considered that running complicated software that your business relies on could reduce reliability simply because it's actually doing something more interesting than serving internal files and transferring e-mail?
Weekend Inspiration? (Score:4, Insightful)
I find it quite disturbing how these companies are blaming downtime on developers. This means that:
a. You have no change control over your environment, and developers can do as they please, hence poor management.
b. Developers are implementing changes that haven't been thouroughly tested. Again poor management.
Technology and competition isn't moving so quickly that you cannot take the time to use a test/qa environment.
Re:Unprofessional development (Score:3, Insightful)
And that is EXACTLY my point. I've been bit by that too many times myself - "Oh, this is so simple I'll just roll it in". Then all goes to hell.
True, there are things that won't break until they go live - that's life in a universe ruled by Murphy. But the idea is to reduce the likelihood of an error as much as possible.
That is why, no matter how tempting, no matter how trivial the change seems, no matter how much it seems like a waste of time, you put it into test first, test as much as you can, then go live.
Have they heard of QA? (Score:5, Insightful)
Re:Not just Programmers (Score:2, Insightful)
Re:Developers shouldn't be able to break stuff (Score:3, Insightful)
Saying "Well, it works on MY machine" is irrelevant - the only box that counts is production.