|
Very good!
I'll not answer it now - far too early and I want to give the others a chance.
Possibly a little too easy?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: Possibly a little too easy?
Yes, that's kind of how my clues are. 
You have just been Sharapova'd.
|
|
|
|
|
Maybe - but it's a good one! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I got an idea what i could be, but well i prefer waiting to see if i was right XD
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Cabin ??
That's what came to my mind when I read the word "chamber"
|
|
|
|
|
Nope, sorry. That's not it.
You have just been Sharapova'd.
|
|
|
|
|
Oh, okay.
Gotta think of something else having a door.
|
|
|
|
|
This one is too easy. I won't tell the answer, so that others can find out.
|
|
|
|
|
Sure. But if no one answers it, I will declare you or OriginalGriff as the winner. 
You have just been Sharapova'd.
|
|
|
|
|
OK...
THAT CHamber has a small door
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I just got it that HATCH is the solution... but darn 2 minutes late!
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Yep! Too easy, wasn't it?
You are up tomorrow.
You have just been Sharapova'd.
|
|
|
|
|
The following thing has happened to me twice now. Is this a company anti-pattern?
An experienced developer is recruited to join a startup looking to build out its team. The team has been working for 12-24 months and has begun to ship. But they have worked very quickly. There are many bugs. There is no documentation. Test cases are minimal. Important internal APIs are, um, quirky. The senior staff are also quirky, not having needed to interact with teams much until now.
The performance of recent hires is compared to the productivity of the senior staff. But the senior staff built the existing software from nothing. They have 12-24 months of experience with the quirky APIs. They actually wrote the code, so they know what it does. They never had to learn it from scratch. Not so the recent hires.
The performance of the recent hires never meets management's expectations. The senior staff, after all, built the whole code base in 12-24 months, but the new guys can't figure it out. The new hires get sacked after six months, to be replaced by newer new guys, but the result is always the same.
Managers at startups always emphasize the need to work quickly. Gotta get a product out before funding dries up. Don't refactor. Don't document. Gotta work quickly. But the result in even a short time is code that is difficult to work with and impossible to learn. It's my personal opinion that these companies' management have done wrong by demanding the original developers work quickly. The result is so much technical debt that it is hard to scale up the company's staff. It takes the same number of months to do a job quickly as to do a job deliberately, you just spend the time doing different things. Getting done earlier is better, but this only happens if the company never needs to staff up.
Anyone else recognize this pattern?
|
|
|
|
|
|
Jörgen Andersson wrote: Yes, it even has a name - Brooks Law[^]
Brooks' Law describes the decrease in producitivity in a project as it scales due to communication issues introduced by adding staff. Since poor APIs and missing documentation amount to poor communication, technical debt multiplies the inherent effect of Brooks' Law.
The result then, is that if you want adding staff to shorten the development time, you have to pay attention to communication, and therefore to technical debt. Right?
Thanks for this observation. It makes more sense now.
|
|
|
|
|
|
Great explanation.
And yes, it happens all over the place.
Now I'm going to invoke a word that could start a hailstorm of replies: Scrum.
Honestly, if you read the book, Scrum: getting twice as much done in half the time[^], written by one of the original creator of scrum, you would learn that all of the things you mentioned are the original reason that they created the Scrum methodology.
The heart of scrum solves those issues. But, Scrum (agile) is explained by many people in the wrong way and developers don't want to hear it. And what those people at that company you mentioned are doing may be called Scrum by them -- even though it isn't Scrum.
That's why to understand everything I'm saying you'd have to read the book.  But that's far to long.
In Summary
You are right. It's an anti-pattern.
|
|
|
|
|
... By the way, thanks for the reference to the book, which I will take a look at; I always appreciate your thoughtful posts.newton.saber wrote: The heart of scrum solves those issues. But, Scrum (agile) is explained by many people in the wrong way and developers don't want to hear it. And what those people at that company you mentioned are doing may be called Scrum by them -- even though it isn't Scrum.
The problem I see with Scrum is that every other person using Scrum considers themselves the sole authority on what it is, and how to use it, and all other people who use it as either misled, mentally unbalanced, or ignorant.
Not to mention the fact the self-promoting gurus of Scrum, busy making a living off their "brand," as u$ual, have a vested interest in resisting the emergence of a "viable heterodoxy" ... even ... at the extreme ... using deliberate mystification of their creed, as if it's not "water by the river" they sell.
But, you would be right to nail me as one of those who have opinions without having drunk the kool-aid
cheers, Bill
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
modified 16-Aug-15 21:17pm.
|
|
|
|
|
Thanks for the great reply.
I agree with you completely.
Way too many people trying to make bank off of Scrum &/or Agile have no idea what the heart of it really is.
The Scrum book I mentioned is really great because the author (as I said, he is one of the original creators of Scrum methodology) tells a lot of stories where he used scrum methodology to solve real problems. THese are stories of how he slowly added elements of Scrum like the "daily stand-up" or the iterative development to get to a process that works the way real work is done.
The book is also very good, because instead of trying to get you to think about checklists of items you must check off to "insure you are doing Scrum" he tells the story of how Scrum came about and why it makes logical sense. He also reveals why some (managers in particular) don't like Scrum : it exposes fake work.
|
|
|
|
|
The most recent company I worked for was an agile shop, with an agile consultant showing the way...sort of. They had the agile values on the wall, but it was clear they had never read them. We scheduled each sprint to 100%, no slack time. Employees were to make that up after hours. If you bid too much time to do a thing (say, because you had no idea how to plug it into the system), the manager (and implicitly the rest of the team) would try to talk you to a lower number. It was very dysfunctional. Technical debt was a huge blind spot in this organization, as was the reality that estimates are always biased on the low side.
What is depressing to me is that this seems to be the norm. Even people who style themselves good managers have apparently not heard of Brooks' Law, even though Fred Brooks almost singlehandedly invented software engineering and wrote it all down in one incandescent book 30 years ago.
Honestly, is anyone working for a really well-run company right now? How did you find your position?
|
|
|
|
|
SeattleC++ wrote: Even people who style themselves good managers have apparently not heard of Brooks' Law
I've been through what you are talking about and it is terrible.
Years ago I lived in the Dilbertonian universe that was several large companies and other smaller companies.
The one thing I learned was :
Managers get the position simply by being available.
They are most usually people with few other skills so someone figures they can do something with people because it seems like maybe they can at least talk.
I was once being reviewed by one of these Sad-Sack Managers and I paused and said, "What was the last book on management you read? Name any."
Insert prolonged silence.
"Okay," I said. "Could you name a recent book that you've read that you could recommend?"
More silence.
Never been a manager, but I've read over 20 management books and what have I learned?
Only one out of 20 managers over 20 years has ever read anything.
Those others are the people who have positional authority, but couldn't even describe leadership let alone exhibit it.
|
|
|
|
|
Scrum solves nothing if your programmers can't code 
|
|
|
|
|
True. Scrum is guidance. If your baseball players can't hit the ball and or catch it you need to start with the basic skills first.
But, imagine if your players could hit, but did not know which way to run the bases. Or, they could field the ball, but had no idea what to do with the ball after they caught the grounder. If they had individual skills but had no idea what the game of baseball is.
That's very similar to developers who are on teams and can "write code" but have no idea how it fits together.
|
|
|
|
|
My trainer told us about Scrum-Butters. Nothing to do with bread and butter, though.
What it means is that "We do Scrum but we don't do these parts of Scrum ...".
And that is a big 'but', ... big enough to be called butter.
On the other front, I feel that your company management should plan for mentors - one senior mentor for two new developers, explaining them the nuances of the functionality, code, etc., and generally increasing the comfort levels of the new hires. And add a metric in the mentor's objectives, directly related to their mentee's productivity. This way, they would be complementing, rather than competing.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
