Flexible Working Good, But Mistrusted

usefool writes "iTNews has a report commissioned by Toshiba Australia, which stated flexible working (the ability for people to work from whatever place offers the greatest suitability and productivity for the employee and their employer) offers up to six times the level of return through the cost savings associated with fewer overheads, parking, technology and recruitment and training costs. However it is perceived as difficult to monitor and supervise, therefore not always practised by employers."

Comments

Re:This is a Double, Double Edged Sword

[shfted!]

Not necessarily so. Quite often, collaboration and other activities require employees being together, with management. Out-sourcing has been shown to work, and its drawbacks known. If it were really the case that the employees could be outsourced, I doubt they'd still have jobs. I don't believe this technology is a huge concern.

Neal Stephenson said it best WRT offshoring

[0x0d0a]

When it gets down to it-talking trade balances here-once we've brain-drained all our technology into other countries, once things have evened out, they're making cars in Bolivia and microwave ovens in Tadzhikistan and selling them here-once our edge in natural resources has been made irrelevant by giant Hong Kong ships and dirigibles that can ship North Dakota all the way to New Zealand for a nickel-once the Invisible Hand has taken all those historical inequities and smeared them out into a broad global layer of what a Pakistani brickmaker would consider to be prosperity-y'know what? There's only four things we do better than anyone else:

music
movies
microcode (software)
high-speed pizza delivery

-- Neal Stephenson, Snow Crash.

Re:This is a Double, Double Edged Sword

[thecampbeln]

Let me clarify... I was not supporting the outsourcing argument (though I am a self outsourced American in Australia, but I don't think that counts ;). I was simply drawing out the logical progression of thought from the point of view of a PHB. Outsourcing != "Local Work at Home Employees" by any means, but do you trust your boss/the shareholders in making that distinction?

As I alluded to above, I believe the drawbacks of outsourcing will be played out publicly sooner rather then later. The case in point is of course the Pakistani transcriber -vs- UCSF for the medical transcription industry, but I think the scarier (for Corporate America) stories are yet to come.

How long until an outsourcing company gets a bid on making a widget for a piece of (let's say) financial software that they just happened to have just completed for a competing product/company. Of course they'll be able to undercut their competition cause they've already got 95% of the code in hand. So they make the necessary modifications and ship off the (slightly revised) code to the second company. With this, you of course get a huge shit fight over who owns the blessed IP of said code. Of course this particular situation could be quietly covered up, but only if the first company never gets wind of it. I'd bet Quicken would love to be able to say that "...our product is soooo good, Money stole some of our source code!"

Or wait until the first outsourcing company goes out of business with projects still in the pipeline. How is small-to-medium company X going to be able to mount a suit in India (or Russia or where ever)? Of course these companies could (and should) get a middle man company to provide such indemnities, but that takes a decent portion of the savings away from outsourcing. Couple this to the time when labor begins to tighten up in the outsourcing markets and any savings could be wiped out entirely.

As for the assertion that all employees that could be outsourced have been outsourced (well... "If it were really the case that the employees could be outsourced, I doubt they'd still have jobs." in your words)... Everyone cannot learn everything new all at the same time (or at least they don't). I'm sure there are quite a few jobs that "could" be outsourced that haven't been. Here in Oz, there seems to be very little in the way of outsourcing, in the programming market anyway. BUT, the technology that enables people to dial in from across the street is indeed the same technology that enables an Indian (or Russian, or) to "take" a job from another country. Though the cat's outta the bag on that one, so there's nothing that can be done about it anyway. And companies rarely outsource a single employee, so they get the "collaboration and other activities require employees being together, with management" in the deal, unfortunately.

self-employment was the solution for me.

[shapr]

I own a company with my fiancee, we've been working from home for a few years.

I really enjoy it. I can sing loudly, jump up and down and scream at my code, or hack obsessively for 36 hours in a row.

We have clients in four countries and the variety keeps me interested and continually improving.

Our overhead is much much lower because we live in a very small (low rent, inexpensive food, etc) town in Sweden and our clients are mostly located in the high population density areas of Europe.

I suspect that the ultimate in flexible working is where companies range in size from one to eight people, with four being the best size.

I believe a good company works like a good jazz band, you're always improvising the next solution, so it's best to have team (band) members you know and trust.

I suspect that a company of one hundred people would be more efficient as many separate partner companies of two to six. 'Corporate reorganization' would still happen, but in that case it would show up in the changing business relations between those many units.

Think of Conway's Life applied to business.

I believe this would dramatically improve the agility of businesses.

Any feedback on these ideas?

have you seen my stapler?

[sevinkey]

I work in an office and talk to almost no one in person. In fact there's been many days when the only conversation I had was over IM with people in the same office, which is exactly what I would be doing at home, only I would know that my employer wasn't reading my conversations.

Re:XP feels the same

[clambake]

Many of the XP stories I've heard have been tales of woe, so I'm interested in hearing about your project. Has somebody on your team written up this success story somewhere?

Well, no success story written anywhere, but even though it's off topic, I guess I can explain a little better here. But before I do, I think I should start by saying that XP woe stores that I have read usually have more to the company NOT following XP practices. If you read any of the major books on they subject, they all say that you can't expect XP to work at all unless you have ALL the pieces, not just a sub-set of them. Our version of XP is "hard core", meaning we DO sweat the small stuff, and subsequently we have a remarkably smooth running system. I've worked at MANY a software company, and from that experience, I have to say that I am absolutly amazed at how we can keep up a bug free system from day to day, with a staff od 80-90% junior programmers, while still introducing new features on a weekly basis, and without missing deadlines.

The single most important facet of XP taht we've been using is so called "test-first" programming. It mean, as it sounds, before you write a line of code, you write the test for it. I used to moan and groan abotu this for a long time, until I started to notice it maked programming remarkably easier both in the long AND the short term.

In the long term, it means that you have 100% automated test coverage at all times, so you can change the system with confidence that whatever you are changing is not going to break something else in the system in any subtle way that you are unaware of.

Before XP, this problem was the bane of my programmign existance... fix on bug and watch another bug pop up somewhere else. As long as you have a system with a full set of FUNCTIONAL tests, then it doesn't matter how madly you manage to mangle the system, becuase if those tests pass (and if you were dilligent and did not add any functionality without adding the test first) then it means your system is production worthy. It also means any bugs you DO create will only ever happen once, because you'll be putting in a test that covers the bug as soon as it is discovered so that it can never happen again without you knowing about it.

Additionally, it means junior programmers who cannot understand the concepts involved in large functionality additions/changes can also participate. a senior member can write the tests, and the junior programmers can "paint by numbers" and implement the functionality. As long as thier code makes the tests pass, it is code that can go out into production. And since the senior member knows the pitfalls that are likely to occour, he can write the tests in such a way that all of the most likely danger areas and edge cases are accounted for.

Now, the junior programmers are still likey to make mistakes from time to time, so the tests first paradigmn is supplemented by agressive refactoring. The rule is, when you see suspiscious or odd code, no matter what part of the system it's in, and no matter what you are currently working on, you drop everything and refactor it.

This is something else I used to moan about, becuase it often means rolling back what you are working on to refactor, which means some lost time... But this is further supported by a policy of very small incrimental change. If you are working on a bit of code and it's taking you more than, say, ten minutes or so to write and check in, more often than not, you've taken too big a bite.

We nibble at the code, making small change after small change, and it means that even if every system were to crash at once, we'd never be more than ten minutes away from what's checked into CVS. It takes practice to know how to do this right, becuase it often involes writing bits of code that you know you will be throwing away in an hour, but in the long run, this system of development allows you a great deal of flexibility in terms of priorities. We can always drop what we are doing