|
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
3. No sys-admin, networking, "how do I setup XYZ" questions. For those use the SysAdmin[^] or Hardware and Devices[^] forums.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
modified 16-Sep-19 9:31am.
|
|
|
|
|
I don't expect everyone, or even a majority, of readers to agree. These are things I wish every Business Analyst (BA), Product Manager (PM), Scrum Master (SM), and Product Owner (PO) could know and take to heart.
1 - Developers are not assembling widgets on an assembly line. Adding more developers, especially after the start of a project, does not speed things up. In fact, it usually slows things down and delays delivery.
2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals.
3 - Team leads for a project should be a senior software engineer with people skills, not a BA, PM, SM, or PO. And certainly not QA.
4 - Look at each project like a bus. Lots of different skills are going in the same direction, to the same destination, but there is only ONE bus driver - the Team Lead.
5 - Limit yourself to describing, in specificity, what you want (requirements), not how to do it. Leave the technology choices to the developers and engineers.
6 - Make time for thorough and detailed planning up front (epics, features, user stories, tasks, etc.), with most of those documents fleshed out by the Team Lead and whomever he or she chooses. Then be agile enough to revise as needed during the project.
7 - If coding has started, and the user stories are still ambiguous, then stop wasting developer resources ($$$) and finish the planning.
8 - Keep meetings to a minimum. Ideally, on Monday or Friday, meet with the leads and developers to look at what was done the past week, what is still being worked on, and what is needed to be worked the coming week. Then leave the developers alone and let them go "heads down" coding. That delivers a better result faster.
9 - A well-managed development team converses peer-to-peer when necessary, without need for a meeting. If a problem arises that developers within a team cannot solve, they will contact the team lead, and if the scrum master's help is needed to get outside resources, it can be handled then.
10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work.
11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion.
12 - Don't go to developers directly without coordinating with the team lead first. Developers on a team need to be coding, not spending time so you can get some data bits for a report. In most cases, the team lead will get what you need.
13 - When a developer is interrupted for meetings or questions not directly dealing with getting code done, it takes anywhere from 15 minutes to 2 hours for the developer to get all the moving parts back in their mind so they can pick up where they left off. Software development is a complex work that takes a lot of intellectual horsepower.
14 - When deciding "we need a meeting" that interrupts developers, calculate the total cost in labor, and ask yourself if the cost is worth what you get out of it. Consider a team of 8 developers and one team lead, at an average labor cost (salary, benefits, etc.) of $100/hr. Your 1 hour meeting just cost $900 and delayed the project by at least 2 hours.
15 - An experienced team lead with business experience and able to describe the technical in non-technical terms can easily reduce the cost of a development team by replacing most, if not all, of what a BA, PM, SM, and PO does. And get it done better and sooner due to lack of overhead. If is far easier for a senior software engineer to learn the business side than for a BA, PM, SM, or PO to learn the software development side.
16 - Agile, Scrum, Kanban, agile frameworks, etc. are not recipes to be followed. They contain principles to be considered and used in the SDLC if and how they provide value. Just read the original Agile Manifesto and see how far today's agile has strayed from it.
17 - Look for generalists, not specialists, on the development team. Hiring specialists (those who work in the specific toolsets being used today) works for now, but not as technology changes. Hiring generalists (those who know software engineering but can adapt and learn whatever toolsets are in use today) gives you people who can efficiently adapt as technology changes.
18 - If you want to learn one new thing, learn what value engineering is.
These opinions are solely my own, and not necessarily those of any current or past employer.
|
|
|
|
|
There's a lot of good stuff in there.
why not a book?
Or at least an article?
I like #5 & #16 a lot.
Also, I took the advice of #18...
What Is Value Engineering?
Value engineering is a systematic, organized approach to providing necessary functions in a project at the lowest cost. Value engineering promotes the substitution of materials and methods with less expensive alternatives, without sacrificing functionality. It is focused solely on the functions of various components and materials, rather than their physical attributes. Value engineering is also called value analysis.
Key Takeaways
Value engineering is a systematic and organized approach to providing the necessary functions in a project at the lowest cost.
Value engineering promotes the substitution of materials and methods with less expensive alternatives, without sacrificing functionality.
It is focused solely on the functions of various components and materials, rather than their physical attributes.
|
|
|
|
|
Value engineering was a significant part of NASA in the 1960s, SkunkWorks in its original days, and in Rickover's Naval Nuclear Power. It has very useful applications in software engineering. One of the most illustrative is the "build vs buy" decisions made often in a project.
|
|
|
|
|
Still represents a master-slave relationship. I wear many hats and don't need a master even when I have to be a slave.
Or, main point: I don't need (want) a middle man to the "real" user.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I am not sure at your point.
If your point is that on a solo developer project, you don't need someone to tell you how to do it, and you can wear all the hats necessary, then I agree with you. My OP was in the context of larger projects where a team is necessary. If I am not understanding your point, please feel free to elaborate.
|
|
|
|
|
I agree with most. 
MSBassSinger wrote: 10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work.
11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up
Actually, it does refer to standing up. Standing up is supposed to keep the meeting as brief as possible.
When done right, especially when in the US and using offshore developers, standups are very important.
|
|
|
|
|
You make valid points, and ones that are commonly known. While what you wrote can be made to work, there are some considerations.
20212 wrote: 10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work.
If the developers cannot be trained to communicate directly with each other and/or the the team lead in a timely manner, when necessary, then I agree with you. Teams that I led, I was able to get my team members to limit the time they spent trying to solve a problem, or if something was unclear, and contact a fellow developer or me directly, instead of holding the problem over for a stand up. What I found was that when my team had adopted the peer-to-peer communication model, stand ups were no longer providing a value, and the weekly meeting was almost always the only one needed. And because problems were resolved faster, we as a team could finish faster.
20212 wrote: 11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up
I have heard the reason you cited from a lot of scrum masters, as that was what they were taught. However, it is more like an excuse thought up to justify the standing, and it is true that standing people speak for shorter periods. The trouble with that is 1) that there is no reference to stand ups in the Agile Manifesto; 2) that sometimes good information can be lost because no one wants to stand that long; and, 3) at least in the US, requiring members to stand would very easily be a violation of the Americans with Disabilities Act (ADA) as standing is difficult for some people, and by allowing them to sit while others stand merely accents them as disabled persons, and would also likely be an ADA violation. I looked into the subject a few years ago, and the actual meaning of a "stand up" was as I stated - to stand up your work, not your body. When I did manage our team's standups, if someone took too long without cause, I gently reminded them to speed it up.
|
|
|
|
|
MSBassSinger wrote: nd the actual meaning of a "stand up" was as I stated
Not sure of your source but clearly different then all of our sources.
Regardless, standups worked great for us. And no one actually stood. The point is, do what works for you.
|
|
|
|
|
Give a man a duck, and he'll feed himself for days; teach a man to duck and he'll avoid low flying objects.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Such as, possibly, ducks.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I'll take a quack at this, but I don't know what the flock I'm talking about. I don't wish to run afowl of the admins here, as they may drake me over the coals. Migrate contribution to this thread is to stop paddling these puns as if they actually fit the bill.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
What quackery is this?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I wonder what Daffy would do?
|
|
|
|
|
Whatever Donald does, of course.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
lol,
I can't help but wonder if this isn't about my sphere packing post. quack quack
|
|
|
|
|
Give a man a fire, keep him warm for a night.
Set a man on fire, keep him warm for the rest of his life.
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
 That's just terrible!
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Give a man a goose and get a punch in the face.
Teach a man to goose and he gets a punch in the face.
|
|
|
|
|
Give me mask and call me Zoro! "Duck" is not what I read the first time. More in the lines of a small pianist. 
There is only one Vera Farmiga and Salma Hayek is her prophet!
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
I'd like to inquire if you are sewing a web of intrigue? Or is some other dodge the point?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
C#: var foo = "foo";
JS: let foo = "foo";
or:
let foo = 'foo';
C#: var s = $"Foo = {foo}";
JS: let s = Foo = `${foo}`;
C#: int Fnc(string a)
TS: fnc(a: string): number
C#: braces are on separate lines
JS: opening brace is on the same line.
C#: if (!String.IsNullOrEmpty(foo))
JS: if (foo)
C#: Reverse(foo);
JS: this.reverse(foo);
or even worse: this.reverse(this.foo);
Half the time I wrote the wrong syntax for the wrong language. 
|
|
|
|
|
Do one language and do it well.
|
|
|
|
|
PIEBALDconsult wrote: Do one language and do it well.
If only I could. 
|
|
|
|
|
With all your years of assembler I'm pretty sure you can 
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
