One of the worst things that can happen to a vendor is to release a product that doesn't work in some way. In software, we call this sort of breakage a bug.
Fixing bugs is something that vendors have to do all the time. Software is much more complicated that just about anything other than organisms. There are simply so many "moving parts".
So why should an SDO or profiler be exempt from this process? The reality is that it shouldn't be. We've discovered many problems with HL7 standards and IHE profiles over the years. And we have the necessary processes in place to fix them. Unfortunately, we don't always have processes that work quickly enough for our customers, implementers or developers. I've seen what it takes to get a "rapid project" off the ground, and it's not something that you want to do lightly, but neither is it as quick or agile as I think we need to be able to support.
In part, I think that is because we lack experience operating at "Internet Speeds" in correcting problems with standards that we are developing at those speeds. But where development needs to complete in 9 months for such a project, fixing a bug feels as if it needs to complete not in 9 weeks, but for some, 9 days. We cannot fix things yet at either of those speeds, but we need to get better at it.
You might argue that we shouldn't have these bugs in the first place. Back when I was in computer sales, we used to say that you could have quality, speed, or low cost, so long as you pick any two. If you want to operate at internet speeds, and do so on a budget, something has to give. I'd be happy to change those priorities, but so long as we don't have time to do things right, we'll always have to make some time to do things over.
Fixing bugs is something that vendors have to do all the time. Software is much more complicated that just about anything other than organisms. There are simply so many "moving parts".
So why should an SDO or profiler be exempt from this process? The reality is that it shouldn't be. We've discovered many problems with HL7 standards and IHE profiles over the years. And we have the necessary processes in place to fix them. Unfortunately, we don't always have processes that work quickly enough for our customers, implementers or developers. I've seen what it takes to get a "rapid project" off the ground, and it's not something that you want to do lightly, but neither is it as quick or agile as I think we need to be able to support.
In part, I think that is because we lack experience operating at "Internet Speeds" in correcting problems with standards that we are developing at those speeds. But where development needs to complete in 9 months for such a project, fixing a bug feels as if it needs to complete not in 9 weeks, but for some, 9 days. We cannot fix things yet at either of those speeds, but we need to get better at it.
You might argue that we shouldn't have these bugs in the first place. Back when I was in computer sales, we used to say that you could have quality, speed, or low cost, so long as you pick any two. If you want to operate at internet speeds, and do so on a budget, something has to give. I'd be happy to change those priorities, but so long as we don't have time to do things right, we'll always have to make some time to do things over.
Good day very cool website Man Excellent Amazing I will bookmark your site and take the feeds also.
ReplyDeleteI'm happy to seek out a lot of useful info right here within the submit we want work out extra techniques
on this regard thanks for sharing.
direct lenders