nowayjose2

I know, but that doesn't stop managers from claiming that any process on some kind of n-week cycle is "agile". Maybe I've had bad luck, but it feels like a lot of companies pick up some agile-for-managers book and implement whichever process is there, minus the parts of the process that make them uncomfortable, and the results are often not great.

The bugs will be very noticeable to stakeholders who are not end users, if they decide to look. The users don't buy the software because they want to; they buy it because they are required to. If groups we're supposed to be accountable to see the shenanigans we're up to and say, sorry no dice, you have to try again with some other company that made their software properly, _then_ the users will be upset because they'll be out mucho dinero for nothing. The end users don't know what rules we're supposed to be following on our end, nor should they have to.

Where I come from, if software doesn't meet requirements and instead produces incorrect results, it's considered a bug. To use another example from a different company I've worked for, I once found out that the financial reports generated by a particular piece of software were all completely wrong due to errors in the way calculations were done. I pointed this out to the higher-ups and they agreed that there was a bug and that all the existing financial reports were in significant error. They refused to let me fix it, not because we didn't have time (there was plenty, and I was otherwise free to work on pretty much whatever was in the backlog), but because fixing the bug would let the customers know that there was a bug in the first place. Some of this data would end up getting passed on to shareholders and the government. Is this not a bug? In the current case, the reason we're not complying with the rules was because of a bad architectural decision that wasn't properly cleared with anyone before it was implemented.

I guess I'm just not on board with the "just following orders" school of software development when the negligence involved rises to the level of illegality and scams. I'm happy to write a lot of software that I personally think is wonky or strange, but for me it stops when we start ripping people off and breaking the law.

I just want to note -- I didn't dismiss the article based on the author's background; I was baffled after reading the article because it made no sense to me when I was reading it from the perspective of someone I initially assumed was a developer. I'm not really sure how someone can develop expertise in software development without having participated in the process, but if you cowrote the article maybe you can explain? Do you agree 97% of developers are following agile principles and that this stability formula is a good way to measure the overall bugginess of an application?

I have a funny feeling that the nontechnical people on my current project would be nodding their heads along to the article, but the truth is that our applications have bugs that 100% of our customers are running into; they simply aren't immediately noticeable to a layperson. That doesn't mean they're not important. The business relies on complying with the rules of third-party organizations and the software is blatantly violating those rules right now. The clients are aware but still choose to prioritize new features over fixing the bugs that are creating these compliance issues. If we're caught out by those third parties before the bugs are fixed, there's a good chance it could sink the whole company. But our users don't "see" these bugs so they're not considered a priority over new products, new features, or anything else marketing might want.

I looked up Pinedo's background and she's not a developer; she's a social media manager. This is kind of what I figured because her perspective on development seemed really out of whack to me. There are many kinds of bugs that can't be measured with a simple stability calculation, and IME there are definitely error states that are worse than death (crashes). Plus 97% of teams are definitely not following agile principles. Every dev team I've ever been on said it was agile, and most of them just meant that there was a kanban board and something that vaguely approximated a sprint.