App Developers Spend Too Much Time Debugging Errors in Production Systems (betanews.com) 167
According to a new study, 43 percent of app developers spend between 10 and 25 percent of their time debugging application errors discovered in production. BetaNews adds: The survey carried out by ClusterHQ found that a quarter of respondents report encountering bugs discovered in production one or more times per week. Respondents were also asked to identify the most common causes of bugs. These were, inability to fully recreate production environments in testing (33 percent), interdependence on external systems that makes integration testing difficult (27 percent) and testing against unrealistic data before moving into production (26 percent). When asked to identify the environment in which bugs are most costly to fix, 62 percent selected production as the most expensive stage of app development to fix errors, followed by development (18 percent), staging (seven percent), QA (seven percent) and testing (six percent).
No surprise (Score:4, Insightful)
43 percent of app developers spend between 10 and 25 percent of their time debugging application errors discovered in production
That seems like an odd metric, but it doesn't surprise me. Production support has always been expensive. Especially if you can't create a full production-like environment with real world data and stupid users to test with.
Re: (Score:3)
As a (fairly large) devops team, we probably spend 1/3 of our time in "production support", from bug investigation to various kinds of automation, it never seems to end.
On thing we don't do though, unless there's no other way, is "debug in production". If anything seems off, you roll back, no question. (And if it's not a recent deployment, you should know that very quickly, too, from logs and metrics.) Figuring out exactly what went wrong can wait, reverting the change before it becomes a customer-visible
Re: (Score:2)
When I said "odd metric" I meant it sounded like a Yogi Berra comment: "Half of the game is 90% mental".
Why not say that on average, development organizations spend 5 to 10% of their time fixing production bugs?
Re: (Score:3)
Most developers seem to forget that companies don't make software so it is comfortable for the developers. Most developers argue with the Product Managers that certain new features should not be done, because they are too much of a hassle or go against a policy in the development team. Most developers forget that the company makes the software to sell, and have a profit in the process. Most developers should do their job faster and with better quality and stop arguing with their Product Managers.
Geez I hope that was parody.
Re: (Score:2)
Most developers should do their job faster and with better quality and stop arguing with their Product Managers.
What do you call 1000 MBAs dying horribly in a chemical fire? A good start!
While you're just trolling, the truth is a PM who actually makes a positive contribution to the feature set of a product is a rare and valuable thing. Mostly product success is luck combined with product quality being "good enough" to not get in the way. Of course, good software ships, and you don't even get to try your luck until that happens.
Re: (Score:3)
Without that feature, there is no certification, without certification there is no go to market, without go to market there is no sales, without sales there is no income for the company an
Time-consuming feature or 0 revenue. Choose. (Score:2)
Yes. As I understand I4ko's post, the feature is "required by regulation". Without it, there is the big fat goose egg of 0 revenue.
Re: (Score:2)
Re: (Score:2)
I've found that to be one of the most frustrating things in dealing with users. If I know what the actual problem is, I can help come up with a good solution.
I've spent time on Stack Overflow reading questions like "How do I do this incredibly stupid thing?" that don't give a clue as to the problem they're trying to solve. It's frustrating, and somebody complains when I comment "That's not the solution, no matter what. What's your problem? It's got to have a much better solution than this."
Re: (Score:2)
Most developers should do their job faster and with better quality and stop arguing with their Product Managers.
Well, Devs *should* argue for things that need to be in there, but yes they should also be professional enough to do what is required to make the product available to customers (certified and all). However, a PM also needs to find a way to make everything fit within the guidelines. It may be that a given feature the PM is arguing for breaks something else that is also extremely important. Thereby if the PM doesn't have a development background then they too are dysfunctional and only being a hindrance to th
Re: (Score:2)
Often PMs aren't unreasonable and don't expect that features are for free. It is perfectly reasonable for a Dev team to present cost estimate which is not only story points but also headcounts, equipment needed, account for decreased productivity and opportunity cost.
Th
Re: (Score:2)
What I have found out, there are some cultures that say "No" when in fact they mean that they won't be able to do it with current resources. Which is absolutely fine to disclose, but for some reason, they don't do it. They just say "no".
Most devs have no clue about project management from a business perspective; your more seasoned devs will (or at least should). "No" will rarely mean "No, that can't be done"; they have to learn how to speak your lingo as much as you need to learn how to speak theirs, and a good PM will help both sides do that.
Often PMs aren't unreasonable and don't expect that features are for free. It is perfectly reasonable for a Dev team to present cost estimate which is not only story points but also headcounts, equipment needed, account for decreased productivity and opportunity cost.
Aside from the MBA speak you have in there...you are obviously detached from the team in any meaningful manner. You might have had a technical background at some point, but you've lost it due to going
Re: (Score:2)
That's the wrong way around. If you're the project manager, you got hired partly for your people skills. Developers get hired primarily for their technical skills. It would be easier for a good p
Re: (Score:2)
That's the wrong way around. If you're the project manager, you got hired partly for your people skills. Developers get hired primarily for their technical skills. It would be easier for a good project manager to learn to speak geek than for developers to speak business.
Devs still need to learn the language of management. Even if they don't go into management it will significantly help with (a) understanding management, and (b) communicating with management; thereby making life a lot nicer. It helps when talking to the PM too; but the PM should be able to talk with the Devs in their lingo - IOW, Dev-Dev is pure dev speak; Dev-PM is mixed dev speak and management speak; PM-Management is pure management speak.
Besides, developers tend to be worse negotiators, and if they're talking a foreign language they'll be even more at a disadvantage. One defense a bad negotiator has is to take a position and stick to it.
Experienced developers are sometimes gun-shy. If you're trying to do a job, and say "We can do it if we get X and Y", and find that you're expected to do it just fine without X and Y, and your complaints get stonewalled, it's going to be much easier for you to say "No, can't do it" next time.
It's possible to wind up in a situation where developers and managers are on the same side, but that usually requires management to understand developers and keep promises.
Consider that many senior devs will eventually do some level of ma
Re: (Score:2)
It does help developers to know management-speak and be able to negotiate, and some senior developers do go into management. However, it shouldn't be expected. PMs should be able to talk straight developer-speak and translate as necessary.
Re: (Score:2)
At start of project:
My estimate: 490 Story points, +2 senior developers, +1 senior QA, 3rd party cost $20k, GA in 9 months
The team estimate: 305 Story points, no new headcount needed, 3rd party cost 15k, GA in 8 months
Status at the 8th month mark:
220 Story points done, 160 newly estimated story points remaining, 80 story point swag remaining, +4 junior developers, +3 junior QA, 6 months away from GA.
Lather, rinse, repeat
I constantly
Re: (Score:2)
Well, let me see how really detached I am from technical work: At start of project: My estimate: 490 Story points, +2 senior developers, +1 senior QA, 3rd party cost $20k, GA in 9 months The team estimate: 305 Story points, no new headcount needed, 3rd party cost 15k, GA in 8 months
It's a matter of how much dev work you are doing versus management work. The more time you spend doing solely management, the less you'll be in touch with real dev estimates, etc as it's impossible to keep up both skill sets without actually using them.
I constantly have to tell the team their estimates are low and unrealistic, as I hear them not discussing corner cases, they take it as an insult to their pride that their estimates are accurate, yet 5 releases down the line they consistently underestimate by as much as 80% and miss release dates by as much as 9 months. Where we were supposed to have a team if 16 senior people, now we have an ever growing team that lastly counted 40 junior people. Every 2-3 months RND management see that they are behind, go out and find some guy fresh out of college, 2 or 3 other developers take 2 months to train the new hire, and as a result we are getting even farther behind, while the new guy is only interested in refactoring to the latest technology buzzword instead of writing new functionality. Refactoring is important, but I generally prefer to have the most senior guys do it, and only after they have been tasked by the Architect to do so.
Sounds like (a) you need some good lessons learned taught among the team, and (b) you need to be applying the standard practice of PM Estimate = ((Dev Estimate * 2) + 20%). Devs are extremely bad at and are not taught how to estimate effort; spend the time to
Re: (Score:2)
Re: (Score:2)
You must be prodyct manager then.
Otherwise your post is incomprehendable.
In 90% of the shops I worked, the developers knew the business better than any product manager ever will.
Re: (Score:2)
I have been in most all places of the lifecycle of a product, both on and off the development team, and also on the customer side. My comment is encompassing all my experience in all those positions, not focusing on a single one.
More often than not, when being on the customer side I have seen products with really good potential shipped pre
Re: (Score:2)
In my experience developers don't usually have access to a competent product manager in the first place!
Re: (Score:2)
inability to fully recreate production environment (Score:5, Insightful)
This is due to finance cheaping out and not allowing the purchase of an exact "test" system to work on. Also, the rush to production is often more important than checking to be sure it all works.
That said, its all a risk/reward thing. Maybe its often better to screw up production here and there than to spend tons of money and time on testing. It all depends if you're building software for a web site or a Mars mission. What is the impact of a failure, and is it recoverable?
Never can though (Score:2)
Even if you can reproduce all of the hardware exactly, you are never going to get the same kinds of results that putting software in the hands of real users will get you.
I'd say far more important than exact hardware duplication of a production environment, would be ease of replication of real production data into QA servers for replication of issues.That includes at any time in QA being able to use the account of any real production user as if you were them... The ability to do that easily saves SO MUCH
Re:Never can though (Score:4, Informative)
That brings back memories:
Me: "It works for me"
Production: "It gives me this error"
Me: "Can you show me the data"
Prod: "It was in Missouri's data for 2014"
Me: "It still works. Can you show me a screenprint of your data?"
Prod: "I'm using this dataset"
Me: "I don't have access to that (expletive unsaid) dataset. Can you show me a (more unsaid stuff) screenprint??"
Prod: *mumbles something about privicy*
Me: *thinks about shooting someone*
Re: (Score:3)
Re: (Score:2)
So you are one of those that keep asking for the screen print! :)
I was talking to the first level help desk of the company that handled the credit card transactions for the websites of the government department I was working at. Their servers were down and I was trying to get them to start working on it. The process for a transaction was that we sent their server an XML file with information about the transaction, they returned an XML file with an URL to give to the user, the user completes the transactio
Re: (Score:2)
It's a bugger because of dependences (it goes pear shaped when this customer orders this product, which is made from parts supplied by these vendors... and none of them are in your test system), but you can cover most of it by making a copy of prod once or twice a month.
Unless, as someone mentioned above, you're too cheap
Re: (Score:3)
Even if you can reproduce all of the hardware exactly, you are never going to get the same kinds of results that putting software in the hands of real users will get you.
There's different kinds of buys, which is why you have different kinds of systems and testing environments.
A dev should be able to have an isolated environment in which to be able to test the various parts. Each part should be able to have a sufficient emulation of external parts to be able to have its own unit and functional testing. From there, several parts should be integrated at a time to do functional and integration testing, eventually building up to the entire system being fully integrated and us
Re: (Score:3)
Re:inability to fully recreate production environm (Score:4, Interesting)
That's not the most prevalent issue. The main issue is the malpractice of Agile methodologies. What happens when you jam a 2 week task into a 1 week time box? Corners get cut in the code, the unit tests, QA test plans and technical debt accrues creating unpredictable results when someone changes brittle code in the future. Most companies are not interested investing in REAL environments and continuous delivery pipelines with:
All of this takes a lot of effort and you don't get it for free running around like a chicken with your head cut-off. Ignore it and you reap what you sow especially in larger scale software efforts.
Re: (Score:2)
Jamming 2 weeks of work into 1 week is going to result in cut corners no matter what methodology you're using (or even what line of business you're in, for that matter.)
If you switch to a methodology where you're estimating in 6 month blocks and you're off by 100% like that, you're now 6 months off schedule instead of one week off -- that's even worse!
Not to say agile isn't misimplemented regularly, but if you're not schedules are off by that much of a margin, you need to start by looking at how you're gene
Re:inability to fully recreate production environm (Score:4, Insightful)
I have never seen a methodology survive its first contact with sales.
Re: (Score:2)
I have never seen a methodology survive its first contact with sales.
That's because sales always asks for flying, sparkly unicorns the defecate gold bricks without considering whether it's actually a reasonable expectation to have. Oh and they promised it to a client so if you could make that happen so they could get their commission and gain favor with the CEO, that would be great. k thx bye
Re: (Score:2)
If you switch to a methodology where you're estimating in 6 month blocks and you're off by 100% like that, you're now 6 months off schedule instead of one week off -- that's even worse!
You apparently have never worked at a place like this: https://www.youtube.com/watch?... [youtube.com]
Trust me that happening once every 6 months is waaaay better than every 2 weeks.
Re: (Score:2)
Why is it that since lately people who obviously have no clue about agil methods are bashing them on /.?
Actually every point you bring up are corner stones of all agile methods I'm aware about.
Re: (Score:3)
Re: (Score:2)
If someone is "fragile" it is hardly a problem of the "method" used ... such teams will be producing bad software ... or good software in a badly way produced, regardless of method.
Re: (Score:2)
But, I think it shows the industry is just really poor at executing it and end up with Fragile instead.
Oh that would be a step up in the environment I'm in. It's all cargo cults here. You have it really good if you get at least Fragile. That means someone is actually trying to do it but failing at execution.
Re: (Score:2)
Video Game industry - Sure some older games had re-releases that fixed some issues, and some games were crazy buggy (youtube Sonic 3 glitches). However, the games typically "just worked" in the 80's and 90's. Compare that to today with multi-GB day-one patches that *should* have been part of the gold disk... had sales/marketing/management not put an improbably deadline on development.
OS Development - See all the zero-day bugs in Window
Re: (Score:3)
It all depends if you're building software for a web site or a Mars mission. What is the impact of a failure, and is it recoverable?
For the Mars mission:
a) about 186mph
b) no
http://www.space.com/34472-exo... [space.com]
Re:inability to fully recreate production environm (Score:5, Interesting)
Where I used to work - big telco software firm whose software generates 80% of the phone bills in the US we had a simple solution to the problem of testing to scale.
We had two identical setups one for production and one for staging. After UAT was almost over we would deploy to staging and then continue UAT on the staging with real world data till the day of cutover (Use Oracle Active-Passive to keep both in sync for the production data while not copying over UAT data to prod)
On cutover day we would change the network switch to now point to the new setup and run scripts to delete the dat created by UAT.
The nice part was now the Prod setup (a bank of 8 servers with 4 quad core CPUS each) was now our backup machine. We would switch it to passive and continue to keep it in sync with prod for at least 7 days. If something horrible went wrong with the new setup. Changing back to the earlier prod machine was a network switch flip. The scripts were a little more difficult this time over especially if the software bug had messed up the data but it was still easy.
Once a production was stable the old prod was now used as staging for the next prod.
What this meant is we did UAT on machines with identical config as the prod machines . It solved a lot of issues and since we also used the machines as the prod backup machine during cutover the cost was taken from the operations budget and not the testing budget.
Our System test and UAT environments were almost as good but not as good as prod and most testing and UAT was done there but the last batch of UAT on the big iron gave good confidence and made cutover day a lot less stressfull than it used to be.
Depends on the system (Score:1)
The in-house ERP system I work on has a great test environment and a huge suite of unit tests, and the corporate environment is pretty well defined, so few (if any) show-stopper bugs ever make it to production and those that do I can reproduce relatively easily.
On the other hand, I also spend time programming machine automation and the idea of having a completely separate independent machine to test your changes on is impractical. Machines that cost hundreds of thousands of dollars don't have test systems
Re: (Score:2)
Why can't you use virtual environments?
Re: (Score:2)
You can but,
1) Virtual machines create their own variable
2) Variable for every different possible configurations of hardware (CPU, GPU, RAM, number of storage drives and type, ports, etc,)
3) Variable for every OS version
4) Variable for every OS configuration option (these can number in the millions per version)
5) Variable for every 3rd party software installation, not limited to virus scanners, disk management tools, 3rd party installers, active applications at time of install, etc.
Just how many different v
Re: (Score:2)
there is no such thing as 100% coverage. But virtual environments give you much more flexibility and can improve you coverage if done properly. You can also define templates which allow you to spin up basic combinations of software configurations as base lines and for regression. I wouldn't use them for performance testing but thye have made things easier in many ways. And increased flexibility and coverage.
I agree there are things you should not use them for, but there are many things they can be used for
Re: (Score:2)
Virtual environments for the expensive machines? Partly because they're not perfect, but largely because the behavior of the machines tends to depend on the real world. They're nice when we can get them.
Most common causes of bugs? (Score:4, Insightful)
How is "management telling people to put it into production as soon as the basic functionality works" not one of the common causes of bugs? At almost every job I've worked at, QA and Engineering would say "We need this much time to test and fix bugs before launch", and management would say "Too bad! Sales already told someone we're launching tomorrow, so we're going live with whatever we have then!"
It isn't the lack of a good test environment, or good test data, it's being told by management that you aren't going to have any time to test...
Re: (Score:2)
Re: (Score:2)
That's understandable (to a degree) in the situation where there was a set schedule ahead of time and things ran over. Then management has to make a decision whether its going to be a bigger hit to their reputation to delay vs releasing garbage.
What we often see though, especially in direct B2B-type software where there's a more intimate relationship between vendor and customer, is that the conversation goes more like this:
Manager: "We want something that does X"
Engineer: "OK that will take 6 months"
Manage
Re: (Score:2)
If your manager is padding your estimate by 2 either you are a really bad estimator or the non dev portions of the org are really dysfunctional.
As for the sales issue we solved it by making sure the sales bonuses are not paid out for at least 1 year after production. If there was a major screwup the customer has probably cancelled the contract and no bonuses were paid if the revenue actually did not come to the company.
Re: (Score:2)
I worked on an application that allowed certain people at large organizations to manage the firms phones on the switch instead of going through the telephone company. The application was provided by the telco and worked with Centrex type phones.
I spent 6 months adding in support for some phone options that the sales team said one customer wanted. After I finally got everything done and tested the customer was informed and decided not to go with it. The options dealt with group pick up and were used for cr
Re: (Score:2)
Doctor, it hurts when I do *this*.
Re: (Score:2)
That presumes ethical management that is willing to accept responsibility for their part in any problems that arise. You're 100% correct that our job is to merely implement the solution and advise of potential problems, and theirs is to accept that advice, balance the pros/cons of a particular course of action, and make the decisions regarding what
Been there, done that as an intern... (Score:5, Interesting)
Re: (Score:2)
Oh look, another humble brag! Must be creimer! How's that fake diet?
What fake diet?
Re: (Score:2)
The one where you violate the laws of physics:
https://science.slashdot.org/c... [slashdot.org]
I went from 325 pounds to 400 pounds when I lifted weights at the gym for a year. I lost fat and gained muscle, but not in the right way. After I stopped lifting weights, my weight settled down to 350 pounds and that's my weight for the last ten years. Although I've been on a low carb diet for the last five years, I reduced my calorie intake to 1,500 calories per day two months ago. This month I weighed 348 pounds.
My statement is factually correct — except I now weigh 345 pounds. What does this have to do with a fake diet?
Re: (Score:3)
This, like every other "I was an intern who saved the world" story, has more than meets the eye.
I work in IT. I save the world every day.
Like, why didn't they simply revert to the previous stable build?
It was a virtual world. Going back wasn't an option.
Re:Been there, done that as an intern... (Score:4, Informative)
That's not always as easy as it sounds. If there was data conversions involved for example, the previous stable build may not even run anymore and would require restoring everything from backup, which may well be a many-many-hour project in itself -- and possibly taking time away from fixing the issue if it was a small-to-mid size company that recycles people into multiple roles (and programmer/IT services is a frequent combination at the best of times.) Just in time to turn around and have to re-convert as soon as you're done because the fix has been completed.
Never mind the fun of the programmers telling you "it'll just be another 2 hours" for 18 hours straight because issues in software tend to branch out in ways that nobody thinks about/remembers and can't include in their estimates until their nose is already in the code and its looking them in the face.
Re: (Score:2)
18 hours Pshaw. Once our production servers had an issue which meant either people could not make calls or we had to let them make them for free. Client decided to let the calls (prepaid calls) go through for free while the rating system was fixed. As onsite representative I was frontfacing even though the fix was being done by Israel team. I was in the NOC for 40 hours straight telling them 2 more hours for thats what the Israel team would say. You know its going to take longer and you know you really cant
Saving the world halfway through doesn't count (Score:2)
I wouldn't be so skeptical. Things like this happen (happened to me, too). However, the "interns saving the world" cry wolves far too often, while lacking the confidence or knowledge to break the news straight to the right people (the devs in GP's case). And as one gets older, it's easier to remember the times when you were right :)
Yeeeup (Score:2)
Yeeeeeup, exactly this. Goddamn do I ever wish I had the resources available to me to actually do my job properly. Company wont provide resources for unit testing the hundreds of variables for our data entry forms that all inter-relate to one-another. Think of it as a massive fucking configuration matrix that shits all over itself. I've proposed for years entirely replacing said system with something extremely simple, but am always shot down. And since we don't have the resources to properly unit test the s
Re: (Score:2)
Given data entry with hundreds of variables that all interrelate to each other, is it possible to do unit tests? If you have ten boolean values that interact with each other, you need a thousand unit tests. It gets worse from there.
I've solved this problem (Score:3, Funny)
I wrote a awesome testing program that resolves the problem of differences between test and production but I can't get it to run in a production environment.
Re: (Score:2)
Time/Money/Quality competition (Score:2)
It's the standard triangle. You can cut from one at the increased detriment of the others. As long as the others are finite resources you always have to cut somewhere. The problem so many developers can't understand is that the 'where' is a business problem, not a theoretical engineering issue.
If it's more important to remain under budget, or be first to market, yeah, quality might suffer big time, and it's easy to ignore the academic's concept of a perfect engineering development lifecycle with a full Q
Re: (Score:3)
I think its not time, money,quality .
The iron triangle is time,money,scope. You can increase or decrease one by changing the other 2 . But if you try to reduce one without changing the other 2, the iron triangle breaks open and the magic smoke which is quality inside the triangle escapes and once it escapes you cant get it back in even if you close the triangle.
Different Concepts Are Needed (Score:2)
The prime directive of anyone associated with building software for end users must be to create bug free, secure systems that are effortless for people to use.
This needs to flow throughout an organization - whether you are the architect, designer, marketer, developer, tester, accountant, whatever. Everyone must be on the same page when it comes to this goal. Everyone needs to really understand what that entails in practice.
I've been both on the building, and receiving end of things when this goes wron
Well, duh (Score:2)
That's what happens when your entire development pipeline aims to put a prototype into production.
Also, "Just validate user input on the front end, it'll be fine once it hits the server" is a recipe for disaster.
Exponential... (Score:2)
It's a well known exponential curve, that apparently needs to be re-learned for every "new technology".
A bug found during requirements analysis has a cost to fix of 1
A bug found during high level design has a cost to fix of 10
A bug found during detailed design has a cost to fix of 100
A bug found during coding/unit test has a cost to fix of 1000
A bug found during system test has a cost to fix of 10000
A bug found in production has a cost to fix of 100000
Re:Exponential... (Score:4, Funny)
Design? Testing? This is the Scrum way !!!! We only have requirements and code and documentation is for pussies.
The propblem is bad accounting practices. (Score:3)
We get hung up on developer costs but never on rework and fix costs. There is constant pressure to deliver untested features to make sales but never much accounting for customers who will walk at the first opportunity or sales which get cancelled due to bugs.
And it has never changed. Watefall, 6 signma, kanban, agile, rapid proto=typing, devops etc. has not made a difference. I have seen no improvement at all over close to 30 years. And people wonder why I drink.
Re: (Score:2)
Tge development method as in agile or waterfall has absolutely nithing to do with the bugs you oroduce, fund or ship.
(*facepalm*)
If you are 30 years in business and can't graps the difference between an opcode (method) and its operands (data, reuslts) then you are since 30 years in the wrong business.
And btw. devops, they have nothing to do with software development, they provide infrastructure, and are 'required' for every orgamizations, ragardless what process you use. Again you are mixing up 'tools' and
Re: (Score:2)
Ok, so what's the point? If they have nothing to do with code what's the point? I thought the point was to deliver better product and code, or rather functionality is the product. Methodologies and philosophies try to deliver the result better but it always seems to go wrong. I spewed out a laundry list of of things which I have always seen breakdown.
The point I was making is that every time some one tries to improve process and therefore hopefully the end result, it gets subverted. I have ideas as to why t
Re: (Score:2)
What is the point of what? DevOps?
Someone has to provide the infrastructure. Instead of having mediocre admins or forcing the developers to do that themselves and hence subtracting some of their work time, you have DevOps. And that is a "role" as in a position in a team and not a method, agile or not.
The point I was making is that every time some one tries to improve process and therefore hopefully the end result, it gets subverted.
Then stop the developers subverting it, plain and simple.
Re: (Score:2)
DevOps is not a development strategy/mehtod.
DevOps is a development methodology, not an infrastructure operations role.
That is bollocks!
How the fuck would that work? What are they developing? They have nothing to do with the software that is developed.
They are glorified all round system admins with a deep understanding for automation and testing.
I worked as DevOps, I DevOps ... no idea what you are doing with DevOps ... that you claim such nonsense.
Re: (Score:2)
Why don't you google for DevOps and check the job descriptions?
Thanx, but I don't watch videos about programming or methods or what ever. For that some guys invented books a few thousand years ago ...
And regarding the text you linked, one of the very first sentences is: "Hereâ(TM)s my take on how DevOps can be usefully defined" ... hardly a general agreed upon definition.
Re: (Score:2)
Ok, so what's the point? If they have nothing to do with code what's the point?
Just because they have nothing to do with the coding part of the process, that does not mean they have no part in the development process. Because (tada) the development process is more than just coding. If you haven't seen a difference in 30 years, man, you are working with some shitty employers.
Re: (Score:2)
Cause or effect? (Score:2)
Respondents were also asked to identify the most common causes of bugs
Surely the cause of bugs is programmers getting it wrong (or, if you want to go to a higher level, errors in the design or specification). All the cited reasons don't cause bugs, they merely prevent their detection.
As for the most environment where bugs are most costly to fix, I would suggest that would be once they reach the consumer and can only be fixed by a product recall? Although once they reach orbit, that can be a pretty expensive place to apply a fix, too.
I guess I'm an outlier (Score:2)
Production bugs do not cost what they once did (Score:2)
Re: (Score:2)
Zero days cost more than all the floppy disks and CDs combined. Back in the day - most things were not networked. Today that's all there is*. Those flaws hurt the customer and the company, and depending on what we are talking about (e.g. network connected cars and industrial control systems) may cause loss of life and property.
The problem space isn't as cut and dried as you would make it out to be.
( * Note: I know that isn't all there is...but I would argue the amount of stand alone non-networked app
Only 25% (Score:2)
Only 25%. You'd be lucky if you have a QA env. In a small shop here is how it goes. Idea, code, does it compile? yes = production! Then the bugs present themselves in all the splendor and you repeat the process. Move fast and break things.
Re: (Score:2)
This is why I recommend an independent rating system in the post above. [slashdot.org]
With a system like that - the consumer/user of software would have an idea about what is the best software to use from the standpoint of quality, user interface, and integration capabilities.
Re: (Score:2)
That may actually work well for a small shop. We've become a lot more risk-averse as we've grown. It takes a little fun out of things, but I'd rather my checkins were good.
Something is missing here (Score:5, Informative)
App developer here.
Something is missing here; namely we spend more time debugging issues found in production, because they get reported. Almost every app nowadays has a crash logger that reports all crashes. Libraries like Twitter's Crashlytics are awesome like that. You get all crashes reported to you, including a ring buffer of the last 100 log messages. It's really, really awesome and I've solved problems in production that wouldn't ever be found normally.
Re: (Score:2)
Impossible (Score:2)
It's just impossible to test everything in your test enviroment. There is NO test suite that will allow you to test everything with a 100% gaurantee it will be bugfree in production. Yes, maybe in a simple very limited app on a very limited OS it will be possible. But with the very extensive configurations (settings/drivers/etc) with modern OSses which run on a gazillion different configured hardware, it's just impossible.
Ofcourse the marketing people of those test suites (and a lot of developers who swear
Phasing out QA (Score:2)
Meanwhile, here in the valley, the latest trend in testing is not testing. Eliminate your QA department today!
Blame Agile (Score:2)
Re: (Score:2)
My experiences with Agile have been much more positive. I think it's a completely valid approach that is really easy to misunderstand and screw up, kinda similar to C++ programming.
QA Incompetence (Score:2)
N/T
Culprit: Code Changes At The 11th Hour (Score:2)
App Developers Spend Too Much Time Debugging Errors in Production Systems
One thing I don't see anyone talking about here is the need to reduce the amount of change (SLOCs, FPs, whatever), done between QA cycles. Any serious system is going to have some sort of QA cycles before becoming available to the consumer.
Take SLOCs for instance. Say, from last release to production to the first QA cycle, you have 1000 SLOCs (or FPs) of change. And experience tells you that, in your organization, it takes 2 weeks of QA to test that much code change. And your first QA cycle is 2 weeks.
S
Re: (Score:2)
I'm floored that 18% of their respondents think that fixing things in development costs more than doing so anywhere else in the process. Simple fact: the further it goes down the chain, the more it costs to fix. I don't care if you're writing software, building widgets on an assembly line, or building a house, it is ALWAYS cheaper to fix the problem BEFORE you add more labor on top of your mistake.
Of the choices they provide, dev is hands down the cheapest place to fix the problem, unless by "expense" the
Re: (Score:2)
It depends on how the developer interprets the question. If the question is interpreted as "where is it most costly to fix a bug", then your answer is clearly correct. If the question is interpreted a "where do we waste the most time and energy fixing bugs, it should (hopefully) be the opposite, i.e. you're going to see more bugs in development, so the total cost of fixing those bugs is much higher than the total cost of fixing bugs in production even though the per-bug cost is lower. This difference in
Re: (Score:2)
Fewer bugs.
--
Signed,
BA in Eng Lit, MBA.
Re: (Score:2)
That's because it's a summary of an article about an ad for another company. (I assume. Unless you work for the company that sponsored this survey.)
And lose the bulk of sales to your competitors (Score:3)
Slow down your production process so you have time to catch them?
That causes end users to choose a competitor's software with tolerable defects over your unfinished vaporware.
Do without the fancies so there are less vulnerability points?
That causes end users who rely on "the fancies" to choose a competitor's software that offers "the fancies".
Re: (Score:2)
I didn't forget, I just don't care. Also, you seem to overestimate how difficult it is to mimic people. And you call me stupid? Now go shag your granny you fat Alaskan cunt.