Become a fan of Slashdot on Facebook


Forgot your password?

Comment Re:Nope (Score 1) 276

Or really, just wait a few years

Problem was, Doc was known (from the future) to get shot less than a week later. They didn't have a few years to wait for gas to be available, or even enough time to fix the engine damage from their attempts to manufacture fuel themselves and try that again.

Comment Re:Nope (Score 1) 276

The problem was that they were under time pressure as (knowing the future) Doc was going to be shot (in unknown circumstances) in under a week. They did try making fuel in Doc's lab and blew out the... fuel intake manifold, I think it was, by getting the octane terribly wrong or something. And fixing that would have taken too much time. If it wasn't for the time pressure, yeah, they could have just gotten fuel somewhere somehow and fixed the car and driven back to the future, but there was no time, so they had to take a train.

Now if it had been Bill and Ted instead of Doc and Marty, they could simply have decided to come back with a portable tank of gas once they get the time machine working again, and them bam, future-them would appear with it right there, and they could go back to the future to buy some gas and bring it back to themselves, then get on with their lives.

Comment Re:Nope (Score 1) 276

The flying circuits were also electrically powered by Mr. Fusion, along with the Flux Capacitor, but the engine ran on ordinary gas, and we know that because Doc Brown said so and that was the entire plot obstacle of the third movie: they're stuck in the Old West with no gas (and busted flying circuits), so they can't get up to speed to return Back To The Future.

Comment Re:Team Reviews are far superior (Score 1) 186

When I look at the list of 100 bugs found by a single tester in my team, who is not busy having review meetings and counting metrics, in a week, I laugh at these numbers.

If your tester is finding 100 bugs a week, you're doing it wrong. Your underlying quality is much too low. It's much more expensive to find a bug by functional testing than by code inspection. This is because all those bugs need to be fixed and retested. This usually requires a rebuild and other ancillary tasks that drive up cost.

Worse, it's usually a geometric progression with this kind of pattern in that for every hour spent bug fixing, there's a ratio of new bugs introduced that have to be removed by the process. This process repeats until the defect count is acceptable. Even with a relatively low co-efficient of bug introduction, the geometric series usually adds 20-30% additional cost to the development.

Sometimes I think a lot of software processes are held up as improving quality not because they actually work, but because the reduced productivity makes the quality metrics look better..

This comes back to my earlier point on people ignoring published research because they feel they know better. Do you know there's actually properly controlled scientific trials that actually establish the truth of what I'm saying? Why is your thought superior to this research? Why is this research defective?

Comment Re:Team Reviews are far superior (Score 2) 186

No offense meant, honestly, but your place sounds miserable to work at. It's not the process, but the ridiculous level of formalization and standardization.

Code inspections work best when they're formal with clearly defined roles and clear reporting steps. There have been large scale studies done that confirm this. The research fed in to the development of the Cleanroom methodology pioneered at IBM.

The less formal the structure, the less well it works.

One of my big bugbears with software development as a craft is our failure to really learn from experience. There were lots of studies done on the craft from decades ago that cleanly establish these basic principals. We choose to ignore them because developers feel they know better than published research.

The truth is that people suck at writing software. Even the very best developers in an organisation are not as a good a team of lower quality people that inspects their own output. Teams > individuals.

Honestly, it isn't as corporate as it first appears. Once the roles are defined, the work turns to inspecting the source. It takes a few seconds to cover off that part of the meeting and from there the real work begins.

There are other benefits

One is that everyone has read everybody's source. There's none of this "Only Bill knows that piece of code." The whole team knows the code very thoroughly.

Another is that relatively junior people end producing code just as solid as person with 25 years experience. They end up learning a lot on the way. Do not estimate the tremendous power of that.

My teams enjoy the process and they certainly enjoy not getting as many bugs coming back to bite them in the future when the feature is out in production. Once they're done, they tend to be done and are free to move on to the next feature.

The benefits of having a cleaner code base, fewer issues and more accurate delivery times has a huge affect on morale.

Comment Re:Team Reviews are far superior (Score 1) 186

Please mention the place so I never get into a mile of it. How would of Linus have created Linux without people like you? Didn't he understand the technical debt he was creating? He could have been finding bugs at a rate of 1.25 per applied man hour instead of actually creating something useful! Silly man. You process guys are useless.

I find this example really odd because Linux is built around a process of a huge amount of code review. They do it differently because they're a distributed team but they absolutely have a rigorous code review process.

Comment Re:Team Reviews are far superior (Score 3, Interesting) 186

You sound like a bean counter, and your organisation sounds like it is hell to work in. 1.25 bugs per man hour? Christ.

Well I'm the head of development at our place so I inhabit both worlds. Businesses like to measure return on investment. By being able to speak that language, I can generally frame activities developers naturally want to do in those terms. This leads to developers getting more of what they want.

You know what developers really, really, really hate? Having to work with technical debt and having no process to remove that technical debt because the program is now "working".

The best way around technical debt is not to put it in to the program in the first place. This process does a sterling job at that. So our developers are generally a pretty happy bunch.

Comment Team Reviews are far superior (Score 4, Interesting) 186

In our organisation, we have teams of six people that work together on their sprint. QA staff are included in this team.

On major features, the team code reviews the feature together in a special session. Roles are assigned. The author is present, a reader (who is not the author) reads the code. There is an arbitrator who decides whether a raised issue gets fixed. This arbitrator role is rotated through the team on an inspection by inspection basis. Finally, there is a time keeper role who moves the conversation to a decision if one topic is debated for more than three minutes.

This process typically finds a humongous number of issues. It takes us about 4 hours of applied effort to discover a bug in pure functional testing. This process discovers bugs at a rate of 1.25 bugs per man hour of applied effort. So if you have five people in a room for one hour, you have applied 5 man hours. You'd expect to find 6-7 bugs. If you include all the stylistic coding standards bugs, this is typically 10-15 bugs per hour.

So while on the surface it looks expensive to have all those people in a room talking. The net result is that it tends to accelerate delivery because so many issues are removed from the software. Better still, the review occurs before functional testing begins. This means the QA staff on the team can direct their testing at the areas highlighted by the inspection process. This further improves quality

It's true that about 50% of the ossies are stylistic issues. But usually we get 1 or 2 bugs per session that present a serious malfunction in the program. The rest could be problems under some circumstances or minor faults.

Team reviews are vastly, vastly superior to pair-programming. There really is no contest.

Comment Re: Trump just says stuff (Score 1) 875

That is a problem, sure, and I would love to see a greater supply of smaller, less expensive housing so that people get get off the rent treadmill sooner in life.

But the bigger problem I see is the existence of the institute of rent (including interest, which is rent on money) in the first place, leaving generation after generation of those families too poor to escape it paying half their life's earnings with nothing to show for it, nothing to leave to their kids, leaving those kids in the same circumstances generation after generation.

If it weren't possible to rent (which doesn't require banning anything, just render certain contracts unenforceable), so housing had to be sold instead (on terms comparable to rent payments, otherwise nobody would be able to buy it and everyone's real estate investments would become worthless), then the money people are currently paying landlords (and banks, for those wealthy enough to rent money instead) would accumulate as equity in housing that they could leave to their children, even if those children have to continue paying it off, and eventually we'd have a world where the housing people are already living in was owned by the people who live in it.

Who, back on point, could then get by with much lower incomes, and so could accept much lower wages, lowering the greatest cost of business, and consequently the cost of the products of those businesses, in turn further lowering the cost of living for the workers who buy those products, who could then get by with lower incomes, etc. All by just removing the parasitic drain of capital-owners charging usury.

Comment Re: Trump just says stuff (Score 2) 875

And the biggest cost to labor is capital, mostly land.

If people didn't have to borrow half a career's income just to have a place to even sit and starve to death in peace, they could work for much cheaper. I live quite luxuriously off a budget that a full-time minimum-wage job could fund if it weren't for rent, and savings to eventually escape from rent, and taxes on the money I have to earn to pay for those things, adding up to almost 300% of what I actually need to consume for that comfortable lifestyle.

Fix the problem of rent (and interest) and get us to a world where people actually own the places they live outright and don't have to pay to borrow them (or money to buy them), and then labor costs can plummet, and the cost of business can plummet with it.

Comment Re:Will we prevent you from silencing others by... (Score 1) 492

The main reason for having free speech is precisely that words are so harmless there is no justification for banning them. No special effort need be made to protect the speech itself, only to protect people from being attacked without justification -- and speaking is never such a justification, because words are harmless.

Comment Re:Will we prevent you from silencing others by... (Score 1) 492

When you imprison someone in your basement, they can't just ignore it and continue on with their lives, or if they feel like it, imprison you in their basement in retaliation.

But when someone says something to you, you can ignore it and continue on with your life, or if you feel like it, say something equally mean back to them.

If by "imprison someone in your basement" you meant "tell someone to go into your basement and stay there", a command that they could ignore or respond to at their whim, then you would have a comparable case. Or if by "silence" you didn't mean "say things that make you not want to speak", but rather "duct-tape your mouth shut", then the cases would be comparable too.

Slashdot Top Deals

It is difficult to soar with the eagles when you work with turkeys.