|
If you push Donald Trump into a vat of concrete, would that set a president?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
and would it break his tweeter?
They call me different but the truth is they're all the same!
JaxCoder.com
|
|
|
|
|
Tweeting from a vat of concrete? Yes, that will set a new precedent president. 
|
|
|
|
|
Well, that's one way for him to get a statue of himself made.
|
|
|
|
|
I've seen a statue of him.
: shudder :
|
|
|
|
|
PIEBALDconsult wrote: I've seen a statue of him.
where's your proof? post the [proud] selfie or it didn't happen!
(and no photoshop fakery - we WILL be checking)
Message Signature
(Click to edit ->)
|
|
|
|
|
|
Wouldn't it spit him back out?
|
|
|
|
|
Careful ... getting close to politics in the lounge.
That's why I avoided the "bad precedent" joke in the original post.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
who says polly ticks?[^] is not allowed?
Message Signature
(Click to edit ->)
|
|
|
|
|
I prefer this one  (WARNING: NSFW): [^]
politics: from poly (many) and ticks (little bloodsucking insects)
modified 15-Nov-19 21:20pm.
|
|
|
|
|
Well it would certainly cement his reputation as the _ president ever!
I, for one, like Roman Numerals.
|
|
|
|
|
In many cases, the team that works on a non-trivial software project includes:
- Project Manager (usually with no software engineering KSAs (1))
- Business Analyst, or "BA" (usually with no software engineering KSAs)
- Scrum Master (usually with no software engineering KSAs)
- Software engineer(s)
- Software developer(s)
- QA
I suggest, drawing on a lot of years of experience, actually doing this, and what I have studied over the years, that replacing the Project Manager, BA, and Scrum Master roles by having those duties for the project performed by a senior-level software engineer with the business, management, leadership, and people skills necessary (as well as hands-on coding) provides these benefits:
- Less overhead, and more resources focused on coding and testing.
- Less time spent in meetings.
- More reliance on expertise and less on the mediocrity of consensus.
- Less of a disconnect between what the customer wants and what is available to the customer.
- Higher quality of product in a shorter time.
- Higher maintainability and extensibility
A team of this design would retain the benefits of agile without becoming mired in the bureaucracy that plagues many agile teams and processes today.
Now it is your turn to comment. I realize that those who make their living from the agile bureaucracy would be in opposition. I wonder how those who actually create, write, and support the codebase might respond.
(1) KSA - Knowledge, Skills, and Abilities
modified 15-Nov-19 11:17am.
|
|
|
|
|
What happens when your "senior-level software engineer" does not want to do management tasks... She might just want to code.
A good project leader (and whatever a scrum master actually do) is and should be a facilitator.
MSBassSinger wrote: - Less of a disconnect between what the customer wants and what is available to the customer.
LOL, the worse thing that can happen to a development team is to be "connected' to the customers wants; you need someone to be the doorman, to filter requests, to prioritize them; and it should not be someone on the technical/coding team; heck, we even try as much as possible to prevent QA to talk to the development team directly; they all go thru proper channels.
I'd rather be phishing!
|
|
|
|
|
Quote: the worse thing that can happen to a development team is to be "connected' to the customers wants; you need someone to be the doorman
You misunderstood the suggestion in two ways.
First, there was no context of forcing a senior software engineer into that position. The intuitively obvious context is that a qualified software engineer, whether she or he, wants to assume that role. Many of us do, some do not, and some truly good software engineers simply are not qualified for those roles.
Second, the software engineer in charge of the SDLC is the "doorman" to customers, business, etc. Team members would not have to be involved directly, as that leans more towards the mediocrity of consensus than excellence.
From a business perspective, if an organization has a qualified and experienced software engineer that can perform those roles, and is willing, it is a better use of available resources to do so, than to waste additional labor costs on a project manager, BA, and scrum master.
Hopefully, that clarifies my suggestion for you.
|
|
|
|
|
Reminds me the changes that IE has gone through in how Dev and issue reports communicate.
Twit Windows Weekly also had Mary Mary Jo Foley i think last year on this change.
Go back a few years and IE had a solid wall between IE developers and outside world. Come a few years back, and I noticed the launch of the modern.ie website. Most likely a slow change, but anyone (or most anyone) can post an issue on the site, and coders can respond directly to those tickets.
Why mention this? I think there is some balance that is needed.
Users direct to the devs? uhm no.
Devs access to users? YES
Users request hopefully benefit with some middle filtering toward the devs.
|
|
|
|
|
MSBassSinger wrote: - Software engineer(s)
- Software developer(s)
What's the difference?
I always see the two used interchangeably (I've had both in my job description while doing the same work).
At my last customer, the project consisted of multiple teams, all working on different parts of the system.
The project manager was completely unqualified to do anything besides making coffee.
Our first scrum master was someone from the team who was also a business analist.
The second scrum master (who replaced the first) was scrum master for another team as well.
All were full time jobs (well, at least our first scrum master worked full time).
In fact, we only got the second scrum master because the first couldn't be scrum master and business analist because it was just too much work.
The project manager (was supposed to) oversaw the multiple teams and keep an eye on spendings and had to report to management and stakeholders.
Putting all those taks on a single person sounds like a recipe for a burn out or a sloppy job (or both).
On the other hand, I'm convinced that company could do with about a tenth of the meetings they had and probably that same amount of (good) people and still gain on productivity 
I agree that it would work for some projects, but not so well for others.
Kind of depends on the size of the project and those involved.
|
|
|
|
|
To answer your first question, in the context of roles, not titles (which can be arbitrary), a software engineer has a broader view and expertise in software projects, including design/architecture, project management, mentoring, value engineering, etc. A software developer lacks the broader knowledge and experience, and focuses mostly on coding.
To your second point, a software engineer that takes on those roles when not qualified to do so, or does not want it, can really make a mess of a project (I've seen it first-hand). However, many experienced software engineers have the KSAs to successfully perform those roles. I've done it in numerous complicated medium to large projects over the years, and others I have known also did it well. There is much wasted and irrelevant work and meetings done in the currently popular team concept that goes away when managed properly.
|
|
|
|
|
I do something similar only I also replace the testers, system admins, designers, front-end coders and toilet cleaners with senior level software engineers with the skills necessary.
I realise those who have just drank from this well that I have heavily poisoned will probably get sick, but everyone else is free to comment.
|
|
|
|
|
A good question.
MSBassSinger wrote: A team of this design would retain the benefits of agile without becoming mired in the bureaucracy that plagues many agile teams and processes today.
Bottom line is, a team, whether it's more flattened as you propose or more hierarchical in the traditional - manager - analyst - team lead - developer pool, including orthogonal members such as QA, customer support, documentation support, along with their respective vertical hierarchies, well...
It's a cliche but a team is only as good as the people in it. All those hierarchical layers and orthogonal departmental "separation of concerns" with their own hierarchies are there for one goal and one goal only: to deal with the fact that teams are never, ever, comprised of 100% good, as in competent, people for the task at hand and to be able to adjust responsively and responsibly based on the composition of the teams.
I am NOT saying that people are always incompetent, it's just that roles and what they are asked to do varies over days, months and years and like my Prius, there are times when I get great mileage and times I don't, and it depends on how I drive, the road conditions, the idiots in front of me, the traffic lights, the deer, etc. Hopefully you get the analogy, that people's competence is a dynamic variable thing.
One more comment regarding the subject line "Does Unnecessary Overhead Adversely Affect Software Projects?"
Your question is biased to the obvious answer, "of course." A better question might be "When does overhead adversely affect software projects?" or even better "How do you determine the peak efficiency of overhead?"
The next question I would ask is: define "adversely affect" and "overhead". Again the bias is that overhead is often overpaid, incompetent management with respect to the cost of the team actually building something. "Supervisor sitting in office vs. construction worker walking on the steel beams 500ft up in the air." At what point does "overhead" in the traditional sense actually become an absolute necessity for the smooth operation of the company?
|
|
|
|
|
Choosing the right people is a necessity for success in any organization. You are describing a situation where there are poor choices for employees.
To answer your questions, "adversely affect" in the context I gave is where the end result of a software project is any combination of late, more buggy than it should be, of lesser quality or functionality, or just flat out fails.
"overhead" in the context I gave are human resources being paid for on the project that do not directly contribute to the creation of the project and do not have expertise in software engineering (thus having to be spoon fed, and worst case, overriding the software engineer(s) on technology issues). The more all team members have experience with software development, the less time spent cross-training or compensating for stupid decisions by non-development team members.
|
|
|
|
|
MSBassSinger wrote: the bureaucracy that plagues many agile teams
You made a funny  .
Software Zen: delete this;
|
|
|
|
|
MSBassSinger wrote: Less time spent in meetings.
for mine this is the most important item.
Too many meetings are all-in, meetings go down the management route, the devs are having their time wasted, then goes down the dev issue, the BA is having his time wasted ...
OK time wasted: an efficient person will switch off and think about their own stuff,
but,
often the opposite happens: person having time wasted feels the need to speak up, so we got the devs weighing in on management, BA weighing in on implemetation ...
and it's one of those power factor things: to discuss one issue:
- 2 people take 4 minutes,
- 3 people takes 9 (or if self righteous 27 minutes),
- 4 people takes 16 (or if they all got masters degrees/PhD: 256 minutes)
Team leader: don't mind non dev, MUST be able handle proj (mgmt, client) meetings
... meetings that devs NEVER attend EVER (proj mgr minutes/messages pertinent items to team)
reason for that: must never have client or non team mgmt ever having any direct influence (nor even direct requests even for the smallest item or info/status report) to the dev team,
- otherwise just go ahead and sack the PM and blame every fault on the most junior dev the day before you start.
Message Signature
(Click to edit ->)
|
|
|
|
|
MSBassSinger wrote: by a senior-level software engineer with the business, management, leadership, and people skills necessary (as well as hands-on coding) provides these benefits:
I agree. But in my experience developers with all those skills are pretty rare.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Quote: developers with all those skills are pretty rare
Rare? Yes. Unicorns? No. I would advocate for going that route when it is possible to have such people. Otherwise, the common approach with higher overhead is the best alternative, IMHO.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
