|
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.
|
|
|
|
|
|
What I wanna know is how the kid got himself a selfie stick...without the mother knowing...
|
|
|
|
|
Dude, your over thinking it... 
|
|
|
|
|
I tend to do that. 
|
|
|
|
|
Not to speak about the smart phone... 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That picture would be the crowning glory of all pictures.
And you could send it anywhere because you would have 4 bars - you know - full cervix!
I wonder if posting it to Facebook would be a breach of the Terms of Service?
I, for one, like Roman Numerals.
|
|
|
|
|
We have an in-house debugging tool, written by yours truly, that we use for capturing TCP/IP-based trace messages between components in our multiple-computer, multiprocessor, multithreaded application. One of my cohorts, through a bug in his component, managed to crash the tool yesterday with one of his messages.
The conundrum: how to debug a TCP/IP-based debugging tool when the bug is triggered by a TCP/IP message?
You go old school: TRACE(...);, which for you youngsters is essentially console output to the Visual Studio debug output window. The TRACE messages got me down to one area of code, a bit of recursive logic used for one of the internal data structures.
This is where it got really old school: I actually printed four pages of code to look at, all at once, on my desk. I haven't done this in years. I wish we had some green bar[^] for our office laser printer to make my nostalgia complete.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: This is where it got really old school: I actually printed four pages of code to look at, all at once, on my desk. I haven't done this in years. I wish we had some green bar[^] for our office laser printer to make my nostalgia complete.
use a color printer. You can add the green bar directly.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
That's the funny part - it's a color printer, so it printed Visual Studio's code highlighting in color. Not bad, actually.
Software Zen: delete this;
|
|
|
|
|
Well done!
After days spent wasted looking at the screen (the logs of both our TCP client and server), I suppose I just need to do the same.
|
|
|
|
|
Gary Wheeler wrote: I actually printed four pages of code to look at
Oooh, I remember that! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
|
Gary Wheeler wrote: This is where it got really old school: I actually printed four pages of code to look at, all at once, on my desk.
I had to do that a couple years ago at the insurance company I was working at. Except it wasn't 4 pages, it was more like 10, and that was one C# method. I added a flowchart to it right next to the code. You wouldn't (or maybe you would) believe the logic errors I found. And this was production code!
Love it when a company claims they practice "Agile", and do code reviews and unit testing. Such was what they said when I "interviewed them". 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
