17 bugs detected including 4 security threats, and we still don’t even know what the programming is supposed to do

Found a couple infinite loops that were causing systems to crash. Slowly coming along. Going to take a bunch of time to allow it to become operational again

I’ve found people who do one will manage the other with ease. But “oops! No ticket” is a canary telling me their commit log is going to be shit.

Thats an astute observation. I really cant refute that haha.

Problem in some teams are the respective audiences for the commit activity v. the ticket activity.

The people who will engage on commit activity tend to have a greater common ground and sensibilities. Likely have to document your work and do code reviews as the code gets into the codebase and other such activity.

However, on the ticket side you are likely to get people involved that are really obnoxious to contend with. Things like:

• Getting caught up in arguments over sizing where the argument takes more of your time than doing the request
• Having to explain to someone who shouldn’t care why the ticket was opened in the first place despite all the real stakeholders knowing immediately that it makes sense.
• Work getting prioritized or descoped due to some political infighting rather than actual business need
• Putting extra work to unwind completed work due to some miscommunication on planning and a project manager wanting to punish a marketing person for failing to properly get their request through the process
• Walking an issue through the process to completion involves having to iterate through 7 states, with about 16 mandatory fields that are editable/not editable depending on which state and sometimes the process is stuck due to not having permission because of some bureaucratic nonsense that runs counter to everyone’s real world understanding.

In a company with armies of project managers the ticket side is the side of dread even if the technical code side is relatively sane.

deleted by creator

A race to accrue as much technical debt as quickly as possible by focusing stricty on individual features while ignoring the long term ramifications of design decisions.

/s

A family of software development processes for teams, which focuses on cycles of quickly building and delivering smaller blocks of program functionally (often just a single program feature - say: “search customers by last name” - or just part of a feature) to end-users so as to get quick feedback from those users of the software, which is then is use to determining what should be done for subsequent cycles.

When done properly it addresses the issues of older software development processes (such as the Waterfall process) in siuations where the users don’t really have a detailed vision of what the software needs to do for them (which are the most usual situations unless the software just helps automates their present way of doing things) or there are frequent changes of what they need the software to do for them (i.e. they already use the software but frequently need new software features or tweaks to existing features).

In my own career of over two decades I only ever seen it done properly maybe once or twice. The problem is that “doing Agile” became fashionable at a certain point maybe a decade ago and pretty much a requirement to have in one’s CV as a programmer, so you end up with lots of teams mindlessly “doing Agile” by doing some of the practices from Agile (say, the stand up meeting or paired programming) without including other practices and elements of the process (and adjusting them for their local situation) thus not achieving what that process is meant to achieve - essentially they don’t really understand it as a software development process which is more adequate for some situations and less for others and what it actually is supposed to achieve and how.

(The most frequent things not being done are those around participation of the end-users of the software in evaluating what has been done in the last cycle, determining new features and feature tweaks for the next cycle and prioritizing them. The funny bit is that these are core parts of making Agile deliver its greatest benefits as a software development process, so basically most teams aren’t doing the part of Agile that actually makes it deliver superior results to most other methods).

It doesn’t help that to really and fully get the purpose of Agile and how it achieves it, you generally need to be at the level of experience at which you’re looking at the actual process of making software (the kind of people with at least a decade of experience and titles like Software Architect) which, given how ageist a lot of the Industry is are pretty rare, so Agile is usually being done by “kids” in a monkey-sees-monkey-does way without understanding it as a process, hence why it, unsurprising, has by now gotten a bit of a bad name (as with everything, the right tool should be used for the right job).

Management where I work finally unbent and admitted that story points were time.

…but also want to continue raising velocity in each sprint.