|
Yeah, my company just went to agile and it's a joke. Now it's about management and not software. It's amazingly inefficient and ... unsuited to projects with any complexity. Since they don't know what they re doing, they are incapable of adapting to reality. All they have is JIRA. I've been working to really know agile so I can make things work but it sure seems silly. It's a management thing.
|
|
|
|
|
All managers should first and foremost be good people and project managers, in which case they don't need to be technical. It helps, but I've seen good managers who weren't. One thing they have to watch out for is BS from those who think they can get away with it, so getting multiple opinions is important. If they institute a poor development process, it's because they think they know better (an ego problem if not technical) or because they bought a line of BS (poor decision making).
It's hard to find talented people, so a team will usually have low performers unless the company is so well off that it can pay for good talent across the board. Developers going into management has always been a thing, for multiple reasons. Some don't like the rigor of getting software right. Others want authority. Others want more pay, which can be a serious problem when a company doesn't realize that its best developers are worth as much as managing directors. Others want to learn more about the business itself--and no one is in a software business. But that doesn't excuse the many who only see software as a cost center, a necessary evil that is simply a factor input to their product. Those are the places most at risk for operating the way you describe. Software as an assembly line. No focus on technical excellence. Pay ceilings for developers. Chasing the latest fad methodology in the hope that it will miraculously improve things.
If you're at a company that's clueless, start to look for another one. They're out there. If you're in a large company, an internal transfer might even land you in a group that is run sensibly.
|
|
|
|
|
Greg Utas wrote: It's hard to find talented people, so a team will usually have low performers unless the company is so well off that it can pay for good talent across the board. Developers going into management has always been a thing, for multiple reasons. Some don't like the rigor of getting software right. Others want authority. Others want more pay, which can be a serious problem when a company doesn't realize that its best developers are worth as much as managing directors. Others want to learn more about the business itself--and no one is in a software business. But that doesn't excuse the many who only see software as a cost center, a necessary evil that is simply a factor input to their product. Those are the places most at risk for operating the way you describe. Software as an assembly line. No focus on technical excellence. Pay ceilings for developers. Chasing the latest fad methodology in the hope that it will miraculously improve things.
Too many generalities in that.
There are companies in the "software" business. Those companies do consulting. They bid on contracts, do designs, implement it, install it and often support it.
It isn't "hard" to find "talented" people. Rather it is an ideal that does not exists. People are people and developers are no different. Most developers are average. Some are better. Some are worse. But the vast majority are average. And when you span the entire spectrum of roles that a developer might need the expectation that they are going to be good at everything becomes an impossible goal. And on top of that one needs to be able to recognize that in the interview process. While failing to recognize that those doing the interviewing are also most likely average. Even more so when one expects a person with perhaps better technical skills to be effective at evaluating in a interview process the actual practical skills of someone else. There are some very rare people do have a knack for recognizing talent when it arrives but it is not something that is teachable (I have seen no evidence in any human endeavor where being above average is teachable.)
This becomes more true the larger the company becomes. Especially when one factors in that it might be more likely to some degree that above average people are more likely to move on. Leaving the ranks behind to tend more towards the average (at best.)
None of the above has anything to do with compensation. Paying someone more doesn't mean they are more likely to be above average. The only effect it can have is that it makes them less likely to be able to find a different job with comparable pay.
Finally of course the above applies to management as well. For example one might have good people skills but not even understand the concept of project management (thus not even capable of seeing that the need exists.)
|
|
|
|
|
Back in the day, well before the words 'Agile' and 'Waterfall' were a thing, we wrote Requirements Docs. The lead users and all of the developers got together many times to create this behemoth, but when it was done, we were left with a SMOP (small matter of programming). Every module was clearly defined by inputs, function, outputs, and ui. Developers were allowed to check out a module to work on and there were no mysteries about the work that needed doing as well as no need to check in with users, much less management. No scrum needed because developers were in constant contact with each other, so we discussed the various ways to solve our specific problems. It was real community that felt like being part of something bigger than our little corner, because we could see it in the Doc.
Reminiscing is fun. Now, back to work!
|
|
|
|
|
If you also did change requests then you were doing Waterfall whether you called it that or not.
|
|
|
|
|
Yes, I recognized it when I learned about agile, since much of the advocacy concerned the differences.
|
|
|
|
|
It is another 'tragedy of the commons'.
But, if all your Agile implementations are as described, you are not 'Agile' you are pseudo-agile - the buzzword has been co-opted to exercise more control, with less respect and less transparency.
Software development has been treated as a commodity since at least the 80's when the bean counters started moving in with their calculators. Unfortunately it is easy to see why; good engineering is expensive and, at least for software, it is un-ending in the sense that it can't easily be 'commoditized' (i.e. it doesn't scale). 'Good' business process depends on exploiting commoditized activities that can start and finish for the lowest cost (they 'scale'). These goals (good engineering/maximal profit) are almost exactly orthogonal to one another when profit depends on scale (these days it often does, but not always).
The list of companies have been bitten by this is long - Boeing would be a good example that springs to mind. Tesla is another, though they have not paid the full price of their wilful neglect of good software engineering yet as society seems to be rewarding death as an integral part of profit.
This problem will only get worse before it gets better (if ever). If you need a company to respect you (some people don't); if they don't already they likely never will, find another company - preferably one that knows the true meaning of Agile and whose success doesn't depend heavily on scale.
Another way of saying all of the above is, don't be on the critical path to profits...
modified 30-Dec-21 10:41am.
|
|
|
|
|
klinkenbecker wrote: But, if all your Agile implementations are as described, you are not 'Agile' you are pseudo-agile - the buzzword has been co-opted to exercise more control, with less respect and less transparency.
Far as I ever saw that is true of every process control that I have ever seen. Every Agile company, every Waterfall company, every adhoc process control idiom.
None of them ever fully and correctly implemented it. I don't doubt that some do it better. Back when I researched process control extensively and read all of the studies on it, there were a very few companies, perhaps 5 in the world, that were far enough along that they could actually measure the progress they were making. The vast majority of the rest, this was for companies actively seeking the goal and attempting to measure what was going on, failed in major ways continuously.
I remember becoming much more aware of this when one company I interviewed at, during the interview process, mentioned that they wanted to start doing source control. As in they were not doing it at all at that point. Source control is one of the measured aspects in process control which is the easiest to actually achieve repeatable and successful results. (Some are much, much harder.) Yet that is not the only company I have seen where it is not happening.
|
|
|
|
|
mkrohn wrote: That is hurting the quality of software. Everyone who has used Office 2003, and Office 365, can note the former has better performance and less bugs, while the later takes more time to start and is more difficult to accomplish tasks,
And then your argument devolved into something that had nothing to do with your point.
Office is a Microsoft product which is driven by the need to make a profit. Note that nothing in that prior sentence says anything about technology nor development. Additionally 365 exists because industry (all sorts) recognizes that service driven revenue is more sustainable than product driven revenue. So 365 is a service where Office 2003 was a product.
|
|
|
|
|
My experience is that the managers using Agile to blue-collarize software development are industry insiders, not outsiders. They try to import a code-at-all-costs mindset from a few companies that compensate their developers highly to lesser companies that treat their workers like interchangeable parts.
Software developers are in some ways victims of our own success. Better programming languages, frameworks, and delivery models we developed over the last 30 years have lowered the barriers to entry into the development field, making blue-collar software development possible. At the same time, for-profit businesses rapidly educating semi-skilled developers are providing a veritable flood of the bluest of blue-collar software workers.
I think we will eventually discover that there are actually two software developer careers, one involving lots of intellectual effort and engineering discipline building tools and frameworks for the other kind of career writing CRUD screens and login pages under relentless Agile deadline pressure.
|
|
|
|
|
I'm not directly involved in software development, but I see a few parallels in another field. I am a retired structural engineer. When I started architects were in charge of the design process. Many are now involved only in concept and the "looks". This is because they failed to learn how to cover the whole range of what is now a complex process. Engineers find that a reducing amount of their work involves an architect.
I read moans on coding forums about how management "don't get it". Management are simply trying to meet the requirements of the person who is paying. If more "software engineers" developed an attitude of "that is the challenge, how can I solve it?" then they would become their own managers.
|
|
|
|
|
The low-code and no-code movement is part of an increasing democratization of programming -- borne of necessity -- extreme necessity. All the way up to "quality of tool from a cereal box" level
|
|
|
|
|
In a well-run shop, the tools stay shiny. The gummy and rusted tools I've seen in my life are usually the result of some idjit leaving them outside unused, rusting.
|
|
|
|
|
A team of theoretical physicists working with Microsoft today published an amazing pre-print research paper describing the universe as a self-learning system of evolutionary laws. Would someone mind hitting Ctrl+Alt+Del?
|
|
|
|
|
Nah, I'll hit Ctrl+Shift+QQ(hitting q twice.) 
|
|
|
|
|
Then they ran out of mushrooms
|
|
|
|
|
Wonde Tadesse
|
|
|
|
|
A pretty faithful reproduction of the classic game With all the awkward movement controls you (hopefully) remember
It's a slow week, bear with us
|
|
|
|
|
Amazon has updated its Alexa voice assistant after it "challenged" a 10-year-old girl to touch a coin to the prongs of a half-inserted plug. The robot uprising has begun
|
|
|
|
|
Alexa came installed on my new laptop. It and McAfee survived less than a day.
|
|
|
|
|
My inner negativist says Alexa is so connected to her web history that stupid viral TikToks prompted this. I would prefer robot overlords.
|
|
|
|
|
At least Alexa didn't say to eat a Tide Pod... or drink bleach, like we should all do 
|
|
|
|
|
oofalladeez343 wrote: or drink bleach, like we should all do
Finally, someone who's more pessimistic than me!
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Yeah sometimes humanity is so darn depressing I just want to find a Halo Ring and activate it. Or do release the Flood...
|
|
|
|
|
Alexa is a baby terminator (T100).
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
