Good Design

OO Coding and Software Principles

Tim Barcz tweeted:

Agree or NO? "Interestingly with the influx of developers moving into OO coding there seems to be a revival of software principles"

Agree wholeheartedly! Here are some considerations:
  • OO coding brings in rigour in coding practices - leading to implicit adoption of good coding methodology.
  • Starting on learning something different and new, such as OO methodologies, may lead to developer to explore and learn good software principles, especially when OO methodologies are closely associated with software principles.
  • OO practitioners are by and large well founded in software principles - so a developer moving to the OO coding methodology would be motivated to adopt good software principles.

Dyson Air Multiplier

Now this is really neat design - we just bought a Dyson Air Multiplier from Bed, Bath, and Beyond (not cheap, but with $66 off and I got to use a 20% off coupon on top of that - what a deal!). It is, of course, a revolutionary design for fans - it has no blades - just a circular cowling-like ring which sends the air forwards, and in addition induces a low pressure volume in the cowling thereby drawing in more air from around the ring. Check out the awesome balloon flight videos on the Dyson page.

I got to try another of James Dyson’s innovative designs - the Dyson Air Blade - at the some of the airports we’ve passed through. Naturally, we had to get the Air Multiplier, being the proud owners of a Dyson DC-17 Animal Vacuum cleaner for several years - which really sucks, in a good way, of course!

AADL Musings

Just got back from a course on the Architecture Analysis and Design Language (AADL) in Huntsville, AL. Stayed right next to the U.S. Space & Rocket Centre but didn’t get a chance to go visit. The Saturn V stands proudly and is visible from my hotel room window.

The AADL lets you model systems as a hierarchy of components, themselves systems. Systems are interconnected via data and event flows. You can also specify properties such as latencies, power consumption, execution time, heat, and weight - both expected and nominal values for each component. Analysis tools, such as those implemented in OSATE, can take these properties and check if the end-to-end latencies, power consumption etc. meet the expected values. Realisations of systems take the form of system implementations and it is possible to try out several different system implementations (e.g. multiprocessor, multicore, uniprocessor) and make several analyses to see which one works best. On top of that the AADL has a very well defined set of semantics for how threads are scheduled, how processes interact, the life cycle of a process, and so on. The AADL is also a standard maintained by the SAE.

I think there’s a place for the AADL in the software development realm - we haven’t done much in the way of rigorous analysis of throughput, many times only as an afterthought. I strongly encourage software system designers and developers to take a hard look at the AADL and see where we all can use the notation and properties to help us better analyse the throughput, latency, and other key performance factors in our systems.