Hydro Ottawa’s new MyHydroLink data is enlightening and frightening, need to cut back on peak usage!!
Good read: Agile Ruined My Life
14 09 2010Daniel Markham has written an insightful post on the agile development on his “What to Fix” blog: Agile Ruined My Life.
I’ve mostly stayed away from the Agile, Scrum, and XP debate since I’m not in that business anymore. I’ve always felt that this was invented before (we taught this at Rational as iterative and incremental development) and that there a lot of hype. This article points out some of these pitfalls, in particular the people who claim to be experts in the field.
Comments : Leave a Comment »
Categories : software development
Software Can Kill, Really
19 10 2009

Image from Wired.com
Wired recently published an article on a software bug in a gamma knife device which is used in various cancer treatments. This device is used to focus high levels of gamma radiation at specific points in the body and provide more “surgical” precision to radiation therapy. The bug they found in this case was that the emergency stop button did nothing when pushed. It is supposed to retract the patient from the machine and turn off all radiation emissions. Now the manufacturer has claimed that additional radiation exposure was minimal, one could see how this could create a very dangerous problem for the patients and the staff controlling the device.
This article brought back memories immediately of the Therac-25 incident (and the Wired article points this out as well) in which several patients were given lethal doses of radiation due to software defects and operator misunderstanding. Regrettably, the Therac-25 was developed right in my home town of Ottawa, ON. Not a proud moment in Canadian software history.
These two incidents point out the fact that software can quite easily kill and the need for not only the right standards (e.g. FDA 510(k)), but also the need for proper design and testing. Of course, I’m going to emphasize the need for tools because, unfortunately, exhaustive testing of these devices is extremely expensive in time and money. We still have a long way to go.
Comments : Leave a Comment »
Categories : software development, software safety, tools cost/benefit
Are hardware guys/gals smarter than us?
6 10 2009Do you think we software guys/gals could design something as complex, using our current processes, tools and working methods as the latest Intel Core i7 processor? It has 731 million transistors and is likely one of the most complex man made objects. I seriously doubt it, certainly not in the time frame that Intel’s hardware engineers can.
How many of the IC designers create chip layouts by hand? Hmmm, none. How many milestone builds, alpha and beta runs do they do? Likely very few. How many times do they leave major defects in shipping product or let customers test the end product? Not for long (since bankruptcy would soon follow).
There are many reasons why they can do what they do and software engineers struggle with the complexities of their job. A major reason is the early realization in the field of IC design that tools are absolutely necessary to get the job done. They use very advanced CAD, simulation tools and high level programming languages like VHDL (which is related to Ada). They also depend heavily if not completely on reusable components. No chip manufacturer would survive by reinventing every ALU or cache controller for each new chip. The combination of advanced CAD tools and reusable components is the key productivity enhancer. For creating quality products, IC designers create models of their products and test them thoroughly before committing anything to silicon. Morever, they simply cannot afford to get it wrong. Intel would suffer serious problems if their latest microprocessor turned out to be a dud. It’s a competitive market you can’t afford a false step.
Software engineers rarely use advanced modeling and simulation tools and high-level languages are often scoffed at. Now, someone will likely argue that, “the tools just aren’t good enough! We don’t have that fancy technology that hardware engineers have!” Early in my career, the first large colour screen workstation that I used, in 1989, was an Intergraph Interpro 32c. Guess who these were for? Us software guys? Nope, it was for PCB layout for the hardware engineers.
Software engineers could have tools like the IC designers if there was a fundamental commitment by the profession to use tools, simulation, high level languages and quality driven development processes. I argue that without the demand for the tools that could make the work easier they won’t be built. I’m sure early CAD tools were awful and I’m sure the engineers complained how it was easier to do it by hand. Somebody persevered because they can’t be saying that today. Yet software engineers are just as likely to pick C, Vi and gcc as the only tools they need just as they would have 10 or 20 years ago. They say “those tools can’t do the magic I do with Vi and C!.” If the commitment to changing the way we do software exists, the processes and tools will come.
There is some hope, such as Motorola’s drive to implement their Six Sigma process across hardware and software. I also think that driving this into the software engineering curriculum is necessary and the ACM and IEEE are working on this. See the SE 2004 proposal. However, from my own education, most of the professors knew how to teach programming concepts and languages but didn’t really have much to offer in terms of processes, tools, quality, methodologies, etc. They simply didn’t have the experience or background to back up that learning. Moreover, industry wants engineers who know things like C, assembler, real-time programming not how to do things though development processes, modeling and simulation (unless, of course, they know all the nuts and bolts stuff too!). Our ability to compete and to build the next generation of products depends on an evolution in the way we do things. I’m not seeing it.
Comments : Leave a Comment »
Tags: software development, tools
Categories : software development, tools cost/benefit, Uncategorized