|
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.
|
|
|
|
|
|
Avijnata wrote: [Y]our company management should plan for mentors - one senior mentor for two new developers, explaining them the nuances of the functionality, code, etc... 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.
Yup, that'd be a great way for them to patch a previous lack of focus on communication. Only they'd have had to internalize the notion that they had a problem.
Here's what they actually did. The senior staff were these very gruff people (the management acknowledged this, wanting to know in interviews if you could get along with "difficult" people). The new hires were made responsible to get answers to their questions from the grumpy senior staff, and if the grumpy senior staff didn't have time to answer lame-ass questions from the n00bs, it was the n00bs fault for not being adequately productive. They took a communication problem and compounded it with another communication problem. Generally the difficult people would be the ones who got tired of the new folks lack of productivity, and sneak off the management to try to get them fired.
The thing about this as a management anti-pattern is that after I left, I've seen these companies advertizing for my position, often every six months or so. They never "got it."
You can't tell them either. That'd be "whining".
|
|
|
|
|
Yep, I've worked on a project with a huge technical debt.
While I'm usually a pretty precise coder I delivered more bugs than usual in that code base...
Every fix I made introduced bugs in other parts of the system.
The guy who made the system would say "ohhh yeah, of course, because..." 
I've even spent days on that project trying to get stuff right (which was really necessary, some routines block the entire server!  )
Unfortunately I gave up after a few days (which really isn't my style).
I stumbled across a method called "Validate", but the first line of comment was "Continue querying the database".
Needless to say that method did A WHOLE LOT MORE than just validation
Days of work without productivity...
Lucky for me the manager knew about the problems we were having and even the guy who made it couldn't seem to fix it.
I work on a different project now 
|
|
|
|
|
Technical debt is a pet subject of mine, and I've posted an article on here[^] about it too.
It's an issue that needs to be addressed by the business. The greater the repayments grow, the harder it becomes to address and resolve. It needs to be visible as an item on the project plan. This gives it the recognition and visibility it needs.
Technical debt won't go away no matter how much we would all like that to be the case. If we take a shortcut to capitalise on an opportunity, then that's all well and good, but you also need to repay back on that shortcut at a later stage.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Everybody loses under such conditions, but the managers usually don't quite get what they are doing. I work at a place where they somehow kept going exactly the same way for 20 years.
Don't let them tell you that you are not good enough for their high standards. They are the ones who are completely clueless, not you.
Don't try to work hard enough to meet their requirements and repair what they messed up collectively. It's a waste of time and your energy. They will not let you succeed, alone out of the fear to look like the donkeys they are. They may always be in a hurry, but they also will find some time for some politics or backstabbing.
If you quietly fight against their selfmade obstacles, they will always tell you that you are not good enough and at the same time hold some carrot before your nose to make you work a little harder yet. In due time you will get a kick into the rear parts, just when the next poor dog comes along and takes your place.
Do yourself a favor. Get out of there.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
This is why most coders are far more efficient rewriting something from scratch than they are modifying other people's code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
