|
In my student days, we read a report on the bug count in OS360 over almost 40 releases. (I believe this is/was a well-known study, referenced in a lot of software engineering texts.) We were shocked to learn that in every release, there were from 1000 known bugs and upwards. It was far from perfect! Yet, customers trusted IBM; a thousand known bugs did not make them flee to other machines or OSes.
Entering working life, I learned that customer tolerance is the norm. As long as there is a workaround, users will do almost anything you tell them to. They learn to work around the issues. They are not academics - they don't want perfection, they want to have their job done, their problem solved.
That actually caused a problem for us: We had to hire interns on short time contracts to do testing at the UI level. We repeatedly saw their performance dropping after a few months: Then they had learned to intuitively avoid operations making the application lock up or the system to crash. They reported everything OK, because they used the application the appropriate way, not the way that crashed it 
When I switched jobs to a Unix / emacs development environment, of course I was told that this software was just perfectly stable; it would never crash. Within a week, I was the infamous software killer, repeatedly going to one of The Great Gurus, showing that if I do so and so and so, emacs locks up, or my workstation crashes. They typically recoiled in horror: But what the elephant made you ever think of doing such a crazy thing? Everybody should understand why that locks up the machine! - Their own instincts had for years avoided those (undisputable) bugs in the software.
I never believe in anyone who claims to have tied up all loose ends, corrected all known bugs, or if not corrected, it is described in the 'Known Issues' document. There will always be loose ends, bugs that will be revealed the day after release, and your documentation of known issues turns out to be highly incomplete.
But calm down. Don't panic. The users will be friendly and willing to do tricks to have their problems solved.
Looking in the mirror: My MSWord 2013 is almost ten years old. Over those ten years, I have learnt at least a dozen different things that doesn't work; I have to do tricks. But I know the tricks; I use them all the time. Maybe they are fixed in a more recent version. Do I bother to update? No. There is of course the economic side, but more important: In ten years, I guess that the number of small and big UI changes is so large that my writing would slow down for months until I had the new UI under my skin. I can live with being a tolerant customer of MSWord 2013
|
|
|
|
|
I liked MSWord 2013 also easy to use and readily available at that time. Now with more and more software and products the market become more competitive and money oriented. I don't had heavy usage of Word 2013 or any document editor so I didn't came across any bugs.
|
|
|
|
|
Check it in, hand it off to the Product Owner, wash my hands, and move on to the next thing.
This is an internal application anyway, with only minor maintenance changes.
|
|
|
|
|
Between 1991 and 1999 I worked on an accounting product for Travel Agencies.
We had releases and I can remember creating the 6 3.5 diskettes that the release was created on.
Making sure that worked was a little nerve wracking.
We did have a meticulous QA person. I got loaned to QA from time to time back then and it was following a 3 inch 3 ring binder of individual screen shots that I had to follow. Tedious. DOS application.
Oh Lord, I just realized that in 10 days I will have been gainfully employed as a programmer for 31 years.
Now I work on a micro-service and we try to deploy every couple of weeks.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
I always wondered how software houses split programs between diskettes, if it was automated or by hand.
I remember Toshiba had me buy a whole box of diskettes, and I used about 31 to create a full Windows 95 installation set (everything that came on the CD since CD-R's were still fairly expensive). Used it once or twice (the laptop did come with a restore CD but it was chock full of junk apps).
By the time I got into a software company, Nintendo forced us to make a single release for all their devices (even if it was downloadable). No patches allowed. Tested and debugged to death for a good 3-6 months.
|
|
|
|
|
I am part of a large dev team, so 99% of all bugs are discovered via local Dev, QA and UAT testing.
We have a dedicated DevOps team that manages our continuous integration builds and pipelines.
We have BAs.
We have a dedicated team of QA testers.
We put everything through a formal UAT process prior to Production deploy.
So, I am never worried at all when my code/work gets deployed to Production.
|
|
|
|
|
...in a total, absolute, panic?! 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
The Lounge[^]
This describes the worst product rollout I have ever been a part of. 
The nature of the project (azure web-based timeclock for 60 sites) meant that at the end of each day, the records would have to be scrutinized and manually corrected and as many bugs fixed as possible before the next day's run, then lather, rinse, and repeat until the system became stable. It was a lot of late nights and weekends! 
"Go forth into the source" - Neal Morse
"Hope is contagious"
modified 7-Nov-22 11:05am.
|
|
|
|
|
I'm retired now but can say that the first release of a new project usually went well.
With hindsight this was because:
a) developers and QA spent a lot of time testing the software.
b) customers were glad to receive new software and were happy that it mostly worked and tolerant of the odd unexpected bug.
As time went by customers expected bugs to be fixed and often used outstanding ones as leverage to ask for new features in future releases.
Eventually, of course, we had to persuade the customer to call it quits and "obsolete" the software.
As in Star Trek the next Generation "time squared" captain Picard kills his own doppelganger from the future so that the Enterprise can move on.
|
|
|
|
|
I was a one man team for long and then I was the lead dev in some other projects... in those, everything was pretty well prepared. Surprises can always happen (Murphy's laws sometimes are bitches), but it was nothing really bad.
In a project I was doing the PLC and the robot, two weeks before launch nothing was moving, the facility manager was getting nervous and contacted my boss. Three days later I upload my versions and started testing, 2 days and 10 to 15 minor fixes later to solve some synchronization / blocking problems, I told the facility manager he could bring the workers to start testing the station with real products. He flipped out, like "WHAT??? the day before yesterday nothing was moving", I just answered "Now it does  "
I have had some more moments like this when customer had to step back from being afraid or even being a jerk (once the end customer even forced the intermediary PL to ask me for forgiveness)... those moments are so damned satisfactory.
Now I work in a big company, and I have little to say about how something ends (or better said, I have a lot to tell, but almost nothing to decide)
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
All projects I've worked on from the beginning went into production without any major issues.
There's always something, especially when switching an entire factory, but nothing that stopped production or couldn't be fixed the same day.
For my current projects, the ones where I'm the only developer, I can do multiple releases a day (and sometimes do).
Only for the really big and scary ones do I tell people to pay extra attention for the day, but it's hardly necessary 
I've been on other projects where every release was a hustle and more bugs would be added.
I've even ditched a company altogether because they chose not to involve me (and I fought for it) and then handed me a steaming pile of crap to fix.
One day, the project manager came to me and asked me "Can you make some screenshots of that functionality?"
And I said "No." and he said "Don't be a smartass, three or so should be enough."
"I can't make the screenshots because that functionality does not exist."
"IT DOESN'T!?" 
After I left they never got it fixed and they lost the customer.
|
|
|
|
|
Every rollout is accompanied by functional, safety and HALT tests.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
But these things happen.
Like when I built the first full prototype of the latest kit ready for the launch in Dusseldorf on fitted the mains lead the wrong way: smoked the main board and there were only three in existence at the time.
On the day the crew is supposed to pack up and head off to the trade show ...
My fault, I was tired (long days for a very short development timescale - only four months!), and it was a stupid cheap, unboxed, unkeyed connector. I changed it across the product range to prevent it happening again.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
