|
|
Smells spammy to me.
(Ah, so it's site-driving then?)
modified 24-Feb-20 14:28pm.
|
|
|
|
|
Did you read it, or just sniff the link on the screen? 😆
The OP is serious question, with a reference to a specific observation. Agree or disagree is fine, but why one comes to that conclusion makes for good discussion.
|
|
|
|
|
PIEBALDconsult wrote: Smells spammy to me.
It did a bit to me, too, but the OP has a few CP articles under his belt, so I temporarily unblocked linkedin and had a look.
Nothing for sale, just an article about what it says on the tin.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I prefer to continue to use the traditional way: Go to the harbor, fill up some developers and drag them aboard.
What? Sailors? That could actually be the reason why all my ships sank and all software projects ended in chaos...
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I can see the overall point. It would be nice to have more technically-minded people in what are traditionally considered non-technical roles since the duties of those roles are inextricably linked to some degree with technical details, but I disagree with shoving PM+BA duties entirely onto lead devs in all but the smallest of projects. There are only 24 hours in a day.
|
|
|
|
|
Good point. If a lead who is a software engineer cannot distill the PM and BA duties down to about 30% of their time, then they are not right for a “Soup to nuts” lead.
I know this approach is feasible because I have done it and known others who did it, and did it well. But many, perhaps more than half of, software engineers just do not have (or want) the multidisciplinary knowledge, skills, and abilities to do it well.
|
|
|
|
|
MSBassSinger wrote: perhaps more than half of, software engineers just do not have (or want) the multidisciplinary knowledge, skills, and abilities to do it well.
Which is fine, and they should be paid less. 
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.
|
|
|
|
|
ZurdoDev wrote: Which is fine, and they should be paid less.
Seriously? The entire march of history is about economic specialization. If someone is great at software, why saddle them with product management, project management, or other things suggested in this article? Those roles should be filled by people who are also good at those roles, but they don't make someone a software team lead from a technical standpoint.
|
|
|
|
|
Greg Utas wrote: If someone is great at software, why saddle them with product management, project management, or other things suggested in this article?
Because it's a small team.
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.
|
|
|
|
|
Sure, but I saw nothing in the article about team size. It seemed to be a general prescription.
|
|
|
|
|
Greg Utas wrote: I saw nothing in the article about team size. I
I didn't read the article and was not limiting my comments to whatever it said. Just a general observation.
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.
|
|
|
|
|
Not a general prescription. General principles that can be applied to teams of various sizes. If teams grow large, then other considerations have to be applied. Should a team of twenty be broken into four teams of five? If so, how is leadership delegated effectively? Those are topics for another day.
I have successfully applied the principles I wrote about to teams from three to twelve. I think that covers the size of most functional teams.
|
|
|
|
|
ZurdoDev wrote: and they should be paid less
Rubbish - you want to take 30% of the time of a highly productive developer and devote it to other duties, bloody silly idea. I don't know about others but as a senior developer I was paid dramatically more than a PM or BA.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Mycroft Holmes wrote: I was paid dramatically more than a PM or BA.
Precisely. So imagine being a good developer and doing project management stuff.
Or, just a developer only. Clearly you should get paid more the more that you do.
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.
|
|
|
|
|
You seem to assume that a developer can have the same quality of skill as a PM/BA, that is highly unlikely if he is highly skilled in one. You have heard of the saying "jack of all trades is a master of none". Seems appropriate.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Your experiences and mine are different. Nothing wrong with that.
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.
|
|
|
|
|
There has been some discussion around this, and it is clear that different people have seen different things work well. There is no single solution. It is up to whoever assembles a team to know (or observe) the strengths and weaknesses of its members. In some cases, combining roles works well. In others, letting people specialize is preferable.
All team members should be compensated for their contribution. No role--product management, project management, senior developer--is inherently more valuable than another. My own experience has been that some outfits value managers more than developers, so they end up with developers going into management when it would have been better, for everyone concerned, if they had remained pure developers.
|
|
|
|
|
Excellent points. A good leader knows how to take solid principles and adapt them to what makes the team work best.
On your point about developers going into management, I have seen that happen, also. That is why I don’t take a leadership or management position unless it also involves coding. I find that being a programmer is essential to really understanding how to lead a team of developers to be greater than the sum of their parts.
Thanks for your post.
|
|
|
|
|
Typical "modern" Boeing style.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Would you be willing to expand on that, for those of us who never worked for Boeing? I am a bot familiar with Lockheed's SkunkWorks, though.
|
|
|
|
|
|
Thanks for adding those links.
No, what I wrote has nothing in common with Boeing or its outsourcing. I do not believe that outsourcing, especially to cheap foreign labor overseas or domestically via H1-B, is a good idea. In almost all cases, the work product is flawed and requires substantial fixing by in-house staff, and put intellectual property (IP) in jeopardy.
|
|
|
|
|
This is where my lack of other development processes (building construction, sales, marketing .ect) gets muddy.
The "traditional" way does work, followed by a sentence of the requirements that fits in.
The improved solution, does work, for certain situations.
Keep in mind, there are people that have worked 20+ years in solely one or the other ways, and might not easily see another way of doing it.
The improved solution looks to tackle some of these BUSINESS issues.
- time, cost, innovation
If you have lots of small projects and some longer projects, a BA can be a big help to shift low cost work out of the time of a programmer.
Also having a programmer at the early stage can help cut through a day or 2 of delay getting a 3 day project finished because they can answer the quick questions, at the expense of them working on some other work
In short, if you have a single long focused project, some middle people might not be needed.
If you are doing lots of short projects, middle people might help.
(a lot of "might" words - people are people and not all people are created the same, but are equal so I don't know how this maths is supposed to work?)
|
|
|
|
|
Thanks for the response. Lots of good points.
I started my programming life long ago by programming computerized commercial environmental systems. That is where I "cut my teeth" on the "Soup to Nuts" concept. I had to quickly learn and be successful with the manufacturing, construction, sales, marketing, training, and personnel management (from electricians and pipefitters to programmers). I drew on the principles I learned then to apply to other projects over the years in more traditional software projects.
You make a good point when there are lots of small projects or a large project. In those cases, I found having a BA to handle the "scribe" duties, and delegating some or most of the project management duties to other senior-level and mid-level software engineers (as their gifts and talents apply) allows the overall approach to work. They key to success, in my experience, is that BAs and PMs do not have authority to manage the project. Their skills are there to assist and report to the team leader.
At some point, when the software development team is large enough to create multiple teams, the software engineer that manages all the teams can focus on looking at new features and technologies, and prototyping so he or she can choose what best fits the goals of the organization, and help teach and mentor the various team leads and team members.
The principles do scale, as long as the person leading has the skills to adapt them to what is needed, rather than follow a recipe.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
