Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment It all comes back to the patent system (Score 5, Insightful) 198

With the patent system as it is, where genetic codes and proteins can be patented, and where protection for drug profits is long and deep, there are situations like this that come up that allow unscrupulous companies to hike drug costs ridiculously like these clowns at Mylan.

Yes, many drug research efforts don't pan out. But Epinephrine has been out for a long time. Is anyone seriously going to try to tell me that $50 in 2007 became $304 in 2017? Even given the bogusly low inflation rates that are officially reported, that's insane.

This is profiteering. If the company didn't need to profiteer in 2007, why do they in 2017? No good reason methinks.

How about the definition of sole source is 'no equivalent product available at present'?

And how about you cap the rates at which drug costs can increase unless the providers can show material evidence that their costs have escalated so much?

I don't have $608 to shell out (US) for something I have to replace every 1-2 years. I'm carrying an old epi-pen that's probably not as efficacious now, but it's likely still better than no pen. I just can't afford the money to get a new one (let alone two, since protocol says you hit yourself with the first and about 30 minutes later the second if you haven't reached emergency medical care).

This should be a true generic. There should be equipment whose patents have an earlier mandatory expiry because they exist in the space called 'in the interest of public health'. I'm not suggesting these guys shouldn't have got their money back, but seems to me they are well beyond that point now.

On the other hand, this is exactly why the government or NGOs should be investing in some sorts of medical research in the public interest and making the product patents entirely open and available.

Epinephrine isn't patented. Its the injector. This seems like the kind of thing a Gates Foundation or even the Government could underwrite the development of (and may have already for Atropine and the like in prior days, if we call those syrettes an early version). Make the injector patent available and then it truly is generic because epinephrine is not patented.

The reality is that big Pharma has great lobbyists, political connections, and lawyers and the whole US patent system around biomedical issues defies any sort of common sense or rational thinking.

I hear rumours of alternatives, but I'm not sure they are available beyond the US borders. The Epipen fiasco and the price rise has hit many of us living in other countries too, but I'm not sure any alternatives exist where I live. I am going to look into that now though.

Patents should help protect innovation, but not form monopolies artificially (well, that may be other legislation that does that but that also needs looked at), should not have extensive duration, and should have clauses surrounding medical equipment that if the equipment price rises too quickly or if the provider becomes sole source, that the patent becomes licenseable by other companies for a very modest fee. At some point, the public interest has merit at least as great as profits for corporations.

Comment Re:Well, it's about time... (Score 1) 299

Where I worked for, our rule was: We deliver on time. We deliver major features for the iteration. Others are negotiable and can be dropped or shifted to the next. This kind of strategy allowed us to develop projects of 18-20 iterations of 3 weeks each and be major feature complete and stable at the end while having delivered working code every 3 weeks to the client so they could start seeing progress and testing and writing manuals and so forth.

On time delivery of an iteration (and repeatedly doing so) gives a customer confidence in your ability. Do this a few times then if you hit a big snag, you've got some cred in the client bank and can negotiate for a feature shift or a partial implementation in an iteration.

When you don't deliver software frequently and regularly, you can get to the end of the project and the customer can shelve the excellently functioning product for some trivial reason (I have seen it happen - insane, but customers make choices like that). Deliver early and often and the customer's issues get identified early (good communication also required) and handled.

Comment Re: Be honest (Score 1) 299

Our approach to that same problem would be:

You have a story that looks like 20 story points but your average velocity for the team is 13. We need to either have a slightly longer sprint (say a third week which should yield about an additional 7 points based on your 13 over 2 weeks or we need to add some manpower to increase our velocity. If those aren't feasible, then we should create two substories that each describe a portion of the work and then work on one in one iteration and one in the next.

You can't be religious about every assertion made in theoretical models of how to apply something. We built (ported) a huge system from one OS to another (N-tier, multiple host types, complex interactions within a software stack on a host and across between hosts) and of course there were some big stories at the start. So we broke them down.

We also knew that in the early sprints, until enough things were together, we couldn't do much functional testing (too many bits needed for anything to work). So we set the testing expectation moderately in the early sprints with more weight on that as enough of the structure came together to allow functional testing.

Seriously, it sounds like you guys are too rigid and too unimaginative by an order of magnitude.

Comment Re: Be honest (Score 1) 299

Not accurate. Management usually has broken out content by major features and knows roughly how many sprints will be needed. It is quite possible to use Agile and have a view to the future, it just isn't set in stone and inflexible.

It sound like most Agile detractors (or detractors of any tool or technology) have had issues with them being put in place in a very inflexible way.

Flexibility (just enough process to be useful, not enough to be cumbersome) is generally the best approach. It's not always a clear point and it sometimes needs to be dynamic. What is known though is that if you try to treat any technology or methodology like a religion (zealotry and can't get enough), bad outcomes ensue.

Comment Re:Be honest (Score 1) 299

Because you are enamoured of process (obviously or these guys wouldn't be employed) and have picked expensive tools, you get down on the method as if it is responsible for those choices....

We used Rally (Rallye?) and it worked very well for us and I don't think it was extortionate in costs.

I've seen a lot of waterfall projects die under the weight of tools and management ideas (too terrible to be methodologies). Same with other ideas like XP Programming (always doing pair work is insane for experienced teams but having that as an option is not).

You can always mis-apply a technology or conceptual approach poorly enough to kill a project.

Comment Re: Be honest (Score 1) 299

If you don't understand the requirements well enough to create broad users stories for features (to be refined and broken down further into smaller subordinate user stories in the iterations where those featurs are worked on), you certainly don't know enough to estimate them and you'll never be able to tell a client or funding source how much the work is going to cost (even broadly).

User stories can be as big a mire as you choose. When we used Agile on a $1M+ contract, we delivered in something like 18 sprints (the last ones were bug killing sprints) and the major items sought were delivered. Lots of 'nice to do' were too, but not all. We only ever spent about one afternoon doing sprint planning (for a team of about 6 at our end and another few overseas) for any sprint (there was preplanning for major features by sprint but we'd have to develop the subordinate user stories at the start of each sprint and put our estimates in).

The project was very successful.

The way a manager of mine once put it: You need process, but just enough. Too much and you die under the weight of it, too little and you get lost in the bushes with no idea when you'll finish or if you'll finish. That applies to any methodology: Waterfall, Objectory, Rational, Agile, etc.

Comment Re:The real problem (Score 1) 299

Mostly not.

For instance, Ottawa was having a train tunnel put through downtown with a limestone geology. The company did test drills all along. Then they agreed to a fixed top end cost (the City forced that as they knew this could go badly). Along the way, sinkholes, collapses, and the predictably bad geology making things tough on the contractor.

Most of these big projects either are so overpriced to begin with to cope with the massive uncertainties or they end up being so late and overbudget it isn't funny.

The thing about the software world is in many cases, if you told the customer actually how much the thing the customer wants done and done right would cost, they'd give up at the start.

Once they are $600K into a project, another $50K here or there (adding up possibly to another $200 or more) is absorbed with ill grace but follows the doctrine of sunk costs and not wanting to lose that investment so sending more money down the hole....

Comment Re:Furthermore (Score 1) 299

One of the reasons clients come to software companies is because they DO NOT understand software. Thus, they want things that they would ask for in other business areas or engineering areas where concrete schedules and tasks (such as building buildings) are not particularly new.

Educating your customer is difficult but having done so, you reap some significant rewards. Also having an uneducated customer can sometimes be worse for your team than no customer at all (I've been on the sorts of projects that broke project teams and lead to significant talent outflow).

Comment Re:Well, it's about time... (Score 1) 299

Accountability can kind of be built into Agile development by the way in which features for sprints are assigned and then results and velocity are tracked at the granular level. Of course, this depends on the how the Agile is attempted. I've seen it done in ways that didn't couple the product closely to the business requirements leading to wasted effort and inefficiency too.

Slashdot Top Deals

The shortest distance between two points is under construction. -- Noelie Alito

Working...