Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Re:Agile! (Score 1) 46

Sprints are SCRUM. You don't need to use SCRUM to perform agile project management.

User stories are an attempt to dress up requirements gathering and the requirements traceability matrix. In project management, a requirement has a business justification and a stakeholder. The Requirements Traceability Matrix (RTM) will tell you the requirement (what?), the stakeholder (who?), the business justification (why?), and the Work Breakdown Structure (WBS) elements which implement the requirement (how?). User stories attempt to make this relatable by describing it in child-friendly terms: "As the manager of finances, I want to be able to compare categorized expenses from different time periods so that I can identify where our major expenses are and how new controls impact those expenses."

As you point out, this is kind of silly for an OpenGL back-end. The user story is something like "as a user on an operating system which doesn't support DirectX, I want to be able to use the software so that I can use the software," or something equally generic. In a RTM, you would simply identify stakeholders as "Linux users" and "MacOSX users", and give the business justification that "the software platform does not support the DirectX back-end". In an actual business, you might identify the product manager as the stakeholder, and use the business justification that demographic data shows interest among MacOSX users. There's no need to invent a fancy story.

If I had a client that would request a demo every 2 weeks I'd have been fired long ago.

If something deliverable can't be produced in 2 weeks, then it can't be delivered every 2 weeks. Plain and simple. Sometimes the next iteration or incremental deliverable takes months to ship. Nobody who knows what they're doing actually implements a 2-week rule; some people use that as a soft guide-line to wring out the WBS (which is used in SCRUM and other agile methodologies), and even then they find that some work packages are necessarily hours or days long while others take longer than 2 weeks.

The standard delineation for work packages is "when the work is broken down to a level at which further decomposition no longer provides a management benefit," which effectively means you only decompose work which cannot be fully understood and measured as a whole unit. "Actigraphy Module" for a generic polysomnography application, for example, is insufficient: you have to break that down at least to include Interfaces, Base Classes, Zero Crossing Class, Time Above Threshold Class, and Digital Integration Class. You might also include, at that level, an Integrations deliverable, which breaks down to include FitBit, Pillow, EightSleep, Jawbone, and other actigraphy-based systems, because "Integrations" is made up of complex pieces and can't be estimated without thinking about the pieces from which it's made.

None of that comes out to "two-weeks". It still comes out to iterative and incremental delivery, user feedback, and compiling lessons learned repeatedly to avoid further defects.

Comment Re:Agile! (Score 2) 46

Actually, agile software development improves quality by delivering on shorter development cycles. What's the point of spending 2 years developing a multi-million-dollar, fully-featured content management system when requirements change out from under you? Every piece that doesn't work as well in the real world as it does for QA will break all at once when you ship it out--welcome to beta software--and features will do what users wanted two years ago.

With agile development, you deliver in pieces. You do iterative development, producing a framework or basis upon which to build further components. You do incremental development, producing fully-functional components which you can deliver immediately for use. Further development on iterative components reveals defects and design deficiencies, and so you refactor, re-engineer, and adjust to meet requirements. Delivery of a working component generates user feedback, which allows you to detect and correct for defects and changes to requirements.

At every stage, you generate more knowledge. Producing each piece, iterating on each framework, and responding to each piece of user feedback generates information which is folded into the further parts of the project. Rather than dumping one piece onto the pile of shit-to-deliver-later and blissfully working on the next, you get told that the shit you just made isn't what we need, and you can reflect on that and the implications for the next piece of the project. That means each piece takes into account the failures encountered so far, and the final product delivers closer to actual requirements at delivery time.

Part of planning is applying knowledge you have. Agile project management allows you to generate new knowledge at every stage and roll that forward into planning the next stage. You can't apply knowledge you don't have.

Comment Re:Great idea... But there is a problem... (Score 1) 287

Is a man-made production process for solid sheets of aluminum oxide and for tiled sheets of zero-distortion interfaced aluminum oxide in nature? Does nature give us a way to perfectly-control the physical and optical properties of aluminum oxide using caveman-level tools?

Gasoline is in nature. We separate it out from a pile of muck pumped out of the ground. The same with iron ore and the steel made from it. There's an argument for communism and socialism which explains that all property is theft because the natural state is that we can go anywhere and take anything, and then suddenly things which we were allowed to take are claimed to belong to someone else and thus have been stolen from us; this argument ignores that human labor is required to acquire, shape, and distribute objects as made from natural things. Giant sheets of alox to precisely-engineered specifications aren't natural, you toolshed.

Comment Re:Great idea... But there is a problem... (Score 1) 287

You cannot be serious... Do you have any idea what kinds of technology advancement NASA has been a primary driver of?

Memory foam, maybe. The general list is things that would have been invented anyway--although some of those things would have instead been DOD projects (satellite communication) more than likely. Velcro was invented by a guy who observed stupid shit like the Greater Burdock sticking itself to dogs and pants.

We've managed to invent things like transparent aluminum without NASA or the DOD; the DOD has been running with it, finding new ways to make it, polish it, and otherwise improve the stuff. In most cases, this is stuff someone already invented but that isn't viable for the consumer market yet, and so is mainly a profit source from government money; in many cases, it's stuff that's too expensive to research at a given level of technology, and becomes viable to invent a decade later; in very rare case it is only uncertain if DOD and NASA interest was the cause of an actual invention or only the cause of it being profitable or invented earlier than it would have been.

People have a hard-on for space travel and war, and they believe all kinds of delusional shit about how things just won't ever happen without a good war to make us invent new tech. No matter how technology marches on in peace time and without public-funded science experiments to fund it, people assert that certain technology must be special and would never happen from just commercial interests. They ignore the real world.

So in short: Grow up and stop believing in Santa Clause.

Comment Re:Great idea... But there is a problem... (Score 1) 287

How would the money be well spent?

If the money is spent paying Google, Netflix, Verizon, or other engineers, we end up with newer infrastructure, better services, and the like. If it's spent building rockets to circle the moon, then we still pay this (not just "we pay it in taxes", but the labor is spent and the labor is compensated--we work and we exchange our time for this), and what do we receive?

Wasteful spending reduces the amount of stuff you receive for the work you do. That's true across an entire economy for obvious reasons (if half the farmers instead make war machines, half the food doesn't get made, and you pay for war machines that only go out to get blown up). What are we gaining by spending $23 billion here?

Slashdot Top Deals

Prediction is very difficult, especially of the future. - Niels Bohr