Become a fan of Slashdot on Facebook


Forgot your password?

Comment Re: Perfect? Really? (Score 1) 340 340

Most importantly, no one is even close to solving no limit -- where you are allowed to vary your bet size. That changes everything.

If we are under the same assumption of unlimited games allowed and unlimited resources, then yes, they have:

Comment Re:Doesn't matter in the end (Score 1) 472 472

I thought the same thing, but git shows that they were written by the same developer in a single commit. This same developer has caused the developers at my company SO much trouble. He documents the stupid things, and performs useless 'no-op' conversions (another example from Python, str is already a string: str = "%s" % str... not only did is the code confusing [str() anyone?], it's a no-op). On top of that, our code is filled with comments such as "This is a hack" followed by 400 lines of illegible, undocumented code (unless you count "This is a hack" as documentation).

Comment Re:You get what you pay/wait for (Score 1) 491 491

Oh, and also, I was basing my comments on previous experience. I have worked using a waterfall model in the past, and in my experience it wasn't usually executed well, or didn't work as well as the team I am a part of now. So no, I don't know the best way to do things, but I do know what has and has not worked for me.

Comment Re:You get what you pay/wait for (Score 1) 491 491

I didn't mean to come across as knocking other approaches. The core of my point was that in my situation, with my team, agile works well. And to address the questions you posed:

Fast - By change of direction, I meant for the REST of the project, not work that was already completed. You can change directions on a weekly basis with agile (if your situation supports it, as someone else suggested, this won't work for the design of an airplane for example).

Cheap - My team tends to use the words priority and value interchangably. The highest priority task is the one that brings the most value to the business as a whole (which can, admittedly, be difficult to judge the "highest" sometimes, but we do our best and people seem happy).

Good - Short development time means we don't have to go back to the research and designing we did 3 months ago to remind ourselves what we're doing. The research and design is done in very small chunks and is usually from the past week. Yeah, some things take more than our one week time to complete, but we have SOMETHING done each week that is measurable, predictable, and best of all, sustainable.

Comment Re:You get what you pay/wait for (Score 1) 491 491

The company I work for employs Agile and Scrum methodologies along with some Extreme Programming mixed in, and I would argue that we achieve all three. I am a part of a team of 6 developers and here is how I believe we achieve all three:

Fast - By only working on the highest priority items, we get the most value out as soon as possible, and are able to switch gears on a weekly basis if the company's direction changes. With a waterfall approach (the most common I think), if the plan changed halfway through, you'd have to scrap everything you've done so far and restart (or risk taking on some serious technical debt).

Cheap - Because we are only completing the highest priority items, we get the most value in the least amount of time. And less time spent means less cost. When we get down to the lower priority items, the product owner can decide on a whim that we don't really need to complete features XYZ, because what we have already completed gives us 90% of the business value for 50% of the cost.

Good - Because our development cycle is so short (1 week), we are always working on things that are fresh in our mind. Also, when we're only focused on one feature at a time, we can really make sure that feature is done right, instead of worrying about how 60 different features are going to fit together (which can lead to some serious over-development and result in more technical debt). Paired programming also helps here, because we have a sort of built in QA as we develop from the person sitting next to us.

The feedback we have received from the company is that we are a marvelous improvement over the previous team, and all six developers have been with the company for less than 2 years. The shared knowledge that is achieved through paired programming has really helped us to excel above the company's expectations. I have some references to some great Agile/Scrum coaches if anyone is interested. Hit me up at Jake{dot}Griffin{at}gmail{dot}com if you're interested.

Real programmers don't bring brown-bag lunches. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.