|
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.
|
|
|
|
|
I agree with Zurodev, the combination of technical skills and the ability to manage people is very rare, I met very few in the 40 years in the industry. I have seen 2 or 3 successfully move from development into management, I have seen many more (including me) fail miserably when pushed into management.
I also know of an organisation that has a permanent, dedicated team looking for such people and they have a retainer package to attract the best.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I agree such people are rare, but probably more of them than you think.
I was lucky enough to start my career when such cross-discipline was more common and expected.
I wouldn’t mind knowing about the organization. They are rare, also.
|
|
|
|
|
I could not agree more with the author.I have over 20 years of experience in IT, and consider myself as such a senior-level software engineer.
Although some recruiters don't consider me as being a senior-level engineer, as I am not up to date with all latest "hypes",
I am quite successfull in almost all my projects.
Part of the secret is my project time distribution:
- I first spent quite some time with the customer and let him explain - in his own way - what he expects.
As I can actually code myself, I immediately can match the customer expectations with the budget and the possibilities.
In my experience this saves an enormous amount of time and money, and prevents the customer from having irrealistic expectations.
- At startup of the project, I prepare the different environments(dev/QA/testing), or let it be done by some experts
- then I spent 20% of my time to real coding. No diagrams, schemes, or other time consuming operations:
this code setup is going to be actually used by my collegues "junior/medior" developers later on.
(by god, I hate that distinction Junior/Medior/senior/Lead Developer)--> consider this as setting up the code structures (Interfaces)
- I present this code setup in a POC to the customer and have some feedback.At preference, I like to do this with some keyusers of the client.
If this is not possible, I warn the client about the risk that the users might eventually not be happy with the end result.
- Once this is done, my collegues start working out my code structures, and I spent time on making analysis,estimations,some raw documentation and presenting the plan to the customer.Here the customer gets another chance to express any wishes he has.
He can also still alter some stuff with very little overhead.Once again, because I know the code,
I can make good estimations on the possible impact of this changes.I also warn the client if some modifications would impact the budget.
- After this phase I go in "support" modus:
- I help my collegues with the code if they have issues
- I revise code
- I write documentation
- I keep in close contact with the customer
- I prepare the test scenario's
-
- And also after project is finished, I reserve some time for feedback/follow-up/maintenance
When I am overloaded/incompetent on a task, I ask help from specialists.
In my experience, meetings are necessary, but only when there are issues or feedback is needed.
When there is significant progress, you can also have follow-up meetings.
And meetings should not take more then 1 hour- never...
You don't really need Agile methodology.
- You need continuous feedback from your client(and he is allowed to express it in any way he wants)
- You need to give continuous feed back to the client about budget and progress.
- You need a well crafted design.(=motivated, skilled professionals)
- You need flexibility as different skills are required during the whole project life cycle : as you can see, I do lots of different things.
And yes, some people are better in one or another niche, that's why I call professionals when I need help.
- You need to be able to make proper time/budget estimations: In my humble opinion,
only the people who can actually do the coding, are able to realistic time estimations
- You need your applications to log as much as possible in Dev phase, but in production you only need an extensive log when errors occur(buffered logs are your friend;)
- You need to cut on time consuming operations as much as possible, as there are:
- No scheduled Meetings, only when needed
- Schemes, designs : make them once you really grasp the needs of the client
- Documentation: is necessary, but inline documentation (like XML style in VS), is far more efficiënt.
For instance: screenshots are very explanatory, but also very time consuming, and when the GUI changes, you need new (time consuming) screenshots
Sorry for the long reply, but the author really is expressing my sentiment, and he hit a nerve ;-)
|
|
|
|
|
Better stated than I did.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
