|
Duncan Edwards Jones wrote: Agile is a team management methodology, not a project management methodology.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Duncan Edwards Jones wrote: Agile is a team management methodology, not a project management methodology.
Which word do you think management see from your sentence? 
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
This is a bit of an odd comment:
Quote: one study performed by Cast Software suggests that there is over $1,000,000 of technical debt, or problems with the code quality, in the average code base.
I'm not sure how they can come to that conclusion? What's average - $1 billion... $5,000..? In either case I can't see how you can end up with $1,000,000 of technical debt and in either case, it's not a big issue.
I haven't noticed any improvement with code quality since Agile started to gain ground. In the end, we have to write code - it's going to contain technical debt, performance and security issues as well as bugs, that's just the nature of it. One thing Agile does do well is push up the cost of projects!
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
As is usual, they mixed up the terms "study" and "dart thrown at a piece of paper with random numbers printed on it".
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The increased acceptance of remote versus co-located teams and the availability of effective tools that enable it are among the most significant trends affecting technology industry employment today. The purple one?
|
|
|
|
|
When will companies and their management realize that all three - having a private space to focus without interruptions, having a co-located group space during the phases of a project where being physically together is really great, and having the ability to work remotely when one wants to take a break from the daily commute or have a change of scenery (maybe it's a gorgeous day and you want to work in the park or on your porch). And the advantage with remote work is that you can more easily control the interrupts -- the phone calls, emails, and Slack chatter and not worry about someone tapping you on the shoulder.
We need all three, and all three are effective and productive when used in the right way and at the right time.
Doors? Even the middle managers at where I work don't have doors. They just have higher cubicle walls.
Marc
|
|
|
|
|
|
Marc Clifton wrote: When will companies and their management realize that all three ...?
Great post, I agree.
Consider this :
If the project were perfectly defined everyone could work remotely without ever meeting.
The less the worker bees understand what they are attempting to create the more they need to hear the chatter that the other worker bees are buzzing about.
Take an extreme example of this extreme idea:
Suppose the project were a form with three buttons. 1 red, 1 green, 1 yellow.
There are three remote devs and each is assigned one button to develop.
The most they have to do is let the others know they've added their button and possibly do a merge of the code. Very little communication is required.
However, if they are all told something like:
Poorly Defined Software Requirements
"Each of you needs to add a control to the main form.
What you do will depend upon what the other dev does."
Suddenly, each of the three devs is like:
Dev 1: "I'm going to add a droplist because I like drop lists."
Dev 2: "Buttons are easy to add and I can always add the event code later."
Dev 3: "I'll add a button because it shows up first in the tool bar."
This Is An Extreme Example
But now, think about all the talking that will have to occur now.
Once the form has those controls everyone will start wondering who is right.
Others may assume the drop list is correct just because they don't think someone would add that arbitrarily. Etc.
The Main Point
Maybe all bad software and all failed projects are simply because the requirements just aren't defined properly? Maybe 99% of the communication is because no one has actually defined what is supposed to be built and even when they do, they communicate it so poorly that real devs who write real code can't interpret the communication.
Boils down to Bad Management. Total cluelessness about how to actually run a software project and build real software.
If the requirements had been gathered properly and the system were designed properly devs could meet very rarely.
But those two things ain't never gonna happen. 
|
|
|
|
|
In my experience remote development only works when the remote developer is extremely experienced and highly disciplined.
|
|
|
|
|
Joe Woodbury wrote: In my experience remote development only works when the remote developer is extremely experienced and highly disciplined.
Agreed, but having an absolute "no remote work" policy is silly. Give people the benefit of the doubt, or if you'd rather, see how they work on site for a while then give them a trial period of remote work.
I mean, if, as a manager, you can't create clear milestones and determine if the work is being done, you've got problems that have nothing to do with people working remotely.
Marc
|
|
|
|
|
|
Marc Clifton wrote: I mean, if, as a manager, you can't create clear milestones and determine if the work is being done, you've got problems that have nothing to do with people working remotely.
That's why you need agile.
... I'm hoping I can run faster than you.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: ... I'm hoping I can run faster than you.
Only if you're more agile! 
Marc
|
|
|
|
|
I have a bit different observation.
Yes the discipline is mandatory, but experience not at all...
|
|
|
|
|
I'd disagree with you about experience. An inexperienced developer will spend too much of his time trying to interpret the requirements and constantly returning to the users for clarification. Or he will just get it wrong and have to redo the solution.
Do not talk to me about inadequate specs or I'll slap you with my used beer coasters.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
First I think there is a lot of room between "extremely experienced" and "inexperienced", nevertheless that problem is not related to remote work.
The same issue can occur in office and the same issue can be resolve from remote.
You can have collaboration, mentoring, pair programming, whatever... all done from remote as well.
I work in fully remote company and I can say that we never encountered that issue.
The only issue that can occur is the lack of discipline and organisation, without that no person can be at least an adequate remote worker.
|
|
|
|
|
If you lack experience of something, you need to talk with experienced people, ergo stay in the office.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
True, if only there was some way to talk to those experienced people from remote (*sarcasm*) ...
|
|
|
|
|
The phone and net meetings are no replacement for being in the same room as the person who's trying to pound new information into your head.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: phone and net meetings
Make me shudder
... such stuff as dreams are made on
|
|
|
|
|
Apologize, I don't want to sound rude, but that is some seriously limited understanding or remote environment...
So in your mind you would use phone and meetings to educate someone, really?
How about some desktop assistance, remote sharing, VNC?
Nevertheless, I've seen a lot of good and bad thinks that come from teleworking, but educating the newcomers is pretty much the same as if you do it in office.
|
|
|
|
|
Stating an honest opinion isn't rude; go for it.
But talking to someone at his desk, where he can scribble diagrams on paper, show you windows, point at things with his finger (and all the while you can see if he's shrugging, etc.), without his having to spend distracting seconds clicking and configuring things to make it possible for him to show you stuff just doesn't compare. Real, human contact wins, every time.
Plus, you have to book remote meetings, rather than just stroll over and chat (and maybe return a couple of minutes later for confirmation/expansion of details).
It's really tricky to use teamviewer/virtual whiteboards/WebEx/etc. at a coffee machine, or walking down the corridor.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I don't know, I get what you're saying and it does make scene, but in practice it's not like that.
When you're educating someone of course you'll need to "book" a remote, but you would do the same in office as well, you would need to schedule a time for this.
Also you can do all those things you mentioned, you and/or him can also point to stuff on screen, show windows, draw stuff etc.
Basically what I'm trying to say is that if learning remotely was so inconvenient then I don't believe that online courses would ever exist, don't you agree?
Also if learning remotely was so inconvenient there would be no sites like CP 
Also regarding the short questions, inquires or issues that a beginner can have, he can just use Slack, Skype, whatever and ask (if needed share or give control of his screen).
I really don't see much difference from going to some person for help and chatting with a person for help.
So in short, I don't see why human contact should wins, everything can be done and explained remotely...
In practice it's really not as you picture it to be. In real life inexperience people don't have problem working remotely, on the other hand some experience people do have that problem...
|
|
|
|
|
Yes, but you're very much focussed on the education element, which is a completely different thing from working with people, perhaps on a project that's a few years "mature".
If you need to learn something from a teacher, 99% of the time you'd do as well reading a book, because the huge majority of teachers know little more than is in the books -- like if you need to learn the latest weird way of typing in a FOR loop, in the langue du jour, no problem! Get the guy on-line or google it.
but if you need to pick specialist knowledge from an expert, because you are now working on a product that he's been working on for years, and knows inside-out (but he is by no means a teacher), then you don't want to sit and listen to a lecture, because that's not what he's good at, and he won't waste his time preparing one.
You need to pick his brains for a starting point, then keep going back with little questions about little details -- and you have to pay attention to how he says what he says, and the doodles and squiggles and gesticulations that clarify and reinforce what he's saying.
If we're talking about someone preparing for months to do a Ted talk, fine; that can be done "over the air", and so can basic meetings (where little would be achieved, no matter how the meetings were held), but to extract hands-on experience and knowledge from a colleague: sitting on the corner of his desk and chatting will get you an order of magnitude more Useful information per minute spent than an on-line chat will, no matter how cool or cute the tech is.
And you really don't want to know how many comparatively useless hours I've spent in discussions held with the three corners of the Earth via various high-tech and ridiculously expensive comms tools.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You misunderstood what I mean by educating, as I previously mentioned I'm referring to a worker.
This is probably my fault because I mentioned online courses, with that I just wanted to emphasize that remote learning is rather common. True, it's not a same learning process but regardless I think it was a valid point.
Mark_Wallace wrote:
You need to pick his brains for a starting point, then keep going back with little questions about little details -- and you have to pay attention to how he says what he says, and the doodles and squiggles and gesticulations that clarify and reinforce what he's saying.
This can all be done remotely, even doodles and squiggles (which are essential to me, I always draw stuff out with my tablet). Regarding the gestures, ok this cannot be done, but if your teaching depends on your gestures then there is something wrong with it.
In short, you can get the required experience and knowledge from your colleague without him needing to prepare some lecture or anything. He would just explain everything in the exact same manner as if he is sitting there right beside you.
Mark_Wallace wrote:
sitting on the corner of his desk and chatting will get you an order of magnitude more Useful information per minute spent than an on-line chat will, no matter how cool or cute the tech is.
Can you provide some concrete example of that, something you found that is easily explainable live, but requires long time remotely?
I work in a company that switched to fully remote for years now and we're somewhat associated with two other fully remote companies.
We all never had an issue with inexperience workers (at least to my knowledge and observation).
FYI we have quite a few mature projects (one of our products is 10 years old, and it's not a legacy product  ).
Mark if you honestly have an experience in working remotely and those conclusion of yours are not based on some subjective feelings, but rather facts, then my conclusion is that if there really are some things that are hard to explain remotely then for that particular job inexperience workers will have problems and for other jobs they will not.
So in short that generalized statement, people who lack experience should only work in office, is not true.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
