|
 and that makes me blue. 
TTFN - Kent
|
|
|
|
|
Software development is not a people management business, it's a knowledge management one.
I am a professional software developer since 1997. In the years i have seen a shift on the type of people in the industry. Initially, it was a very respectable engineering position, who were there, were for love to the work, not for the love to merely have a decent job.
As the years passed, software become eating the world, and that has gaining the attention of many type of people, for one side, you have the people that wanted to join the industry in the side of IT worker, and in the other side, people from other industries who wanted to change careers to a most redituably one, and picked arrogantly the people management side.
So the industry is getting crowd of managers from outsider industries , who cannot be as facilitators as required, and tend to have a micromanagement and pressure way of people management, under the umbrella of "Agile Process"
Those outsider managers are easily identifiable, they tend to hire younger and junior people, easily manageable.
Thats what have leaded to agile process management, just the necesity to incorporate outsider management to the industry. So the new equation was, code fast, micromanage people, then let QA do their job.
This is not an efficient way of work. Its very dangerous, because it's a tradeoff between engineering excellence, with easy of manageability.
This outsider invasion of the tech space, is driving senior developers to migrate to management positions, sometimes against their wish, because having a bad process quits the beauty and the purpose of the chosen activity, and they feel an urgent need to escape from that hot position. This and end up hurting the development ecosystem as a whole, because what once was a white collar craft ends up being a blue collar trade.
There are many sons of this industry though, that betray his profession and takes it as an opportunity to "give the power to the masses", they see themselves as "tech evangelizators", so they fund coding camps, and lower the entry barrier. I think they are creating a new type of profession, they are skiming the craft, they are blue-collar-izing and turning this space into a trade to earn money. 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, is like they are depowering the user, which is going against the initial reasons we as developers are here, and the reason the personal pc industry boomed in the nineties.
|
|
|
|
|
mkrohn wrote: Initially, it was a very respectable engineering position
You make a very interesting point. If I compare the example of a professional in another field for example a civil engineer who builds bridges tunnels and roads. The engineer is the final authority who signs off on a plan or an item of work that has been completed. The "signoff" of the engineer means that the work has been completed to professional standards and in compliance with the standards of the civil engineers registration board. There is no junior/senior "people manager" making the decision.
Software engineering has lost the professional standing it started with and has become just another type of resource in a project. This is even more pronounced in the Agile world where if timelines are under threat more "resources" are applied irrespective of the reason behind the delay, which may be a complex technical issue which has to be worked through.
For myself personally, I am experienced and knowledgable enough to refuse Agile projects and I still am able to get enough work where I can retain sufficient authority to refuse to release software I am not happy with.
I'm old and I know stuff (this is a quote from another forum member unfortunately I cannot remember their name)
|
|
|
|
|
The white collar/blue collar distinction is interesting. As the software discipline (employment space) expands there becomes a need for gradations in the type and organisation of the work.
The vast quantity of mundane software being generated (with occasional gems) tends to a more narrow focus on individual employee capability. Compare this to workers in construction (aka Civil engineering as per brisby's reply) where there are lots of different trades which can be loosely matched to folks from different code camps in terms of particular practical skill sets.
With scale comes administration and bureaucracy, and managers. But there is still a need for technical knowledge based competence. Software Engineering is still in its infancy with an academic/R&D overhang. The balance between 'Practical Men' versus 'knowledge and theory' has a long history [e.g. Preece/Heaviside, 1889].
|
|
|
|
|
All correct, and I have been programming since 1983.
I quit a job of 9 years in a large company because of Agile's kindergarten practices adopted by higher management being sold that this crap is going to make everything better.....not.
But instead of joining that nonsense I found an IT programming job in a smaller company where RESULTS are the primary factor, not kindergarten nonsense.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
