Perspectives

$80,000.  That was the amount I was recently quoted for a certified RTOS package.  The amount was per processor configuration, with an expected lead time of about eight months. The therapy device my client was developing had two similar, but not identical ARM processors, so their cost would have been $160,000.  The package would have included a customized report for each CPU configuration, support for representing the RTOS package to the FDA, and changes to that package if the FDA required them.

Software architects working on business platforms, medical devices, or aerospace systems may all carry the same title, but the role's practical demands vary by setting. At first glance, it might be hard to notice the differences. The architect defines structure, sets boundaries, shapes interfaces, allocates responsibilities, and establishes technical constraints that other engineers will work within. The architect doing safety-critical work is the same role, but with a rigor that might seem impractical to those who haven't lived it.

I have a challenge for you.

I contend that I can take a moderate-sized software unit, say 5,000 to 10,000 lines of code, from conception through verification at least twice as quickly as the most productive developer on your team.

[Originally Posted on LinkedIn]

This article reaches into the wayback machine. I drafted it many months ago in response to to a then-fresh post. Due to other distractions around my then-upcoming book, I forgot about the draft. Yet, the topic is still relevant.

A discussion sparked by Jeffrey Cooper's post on refactoring versus upfront design has highlighted one of software development's most heated debates. The conversation revealed diverse perspectives on how we should approach software design — perspectives that don't necessarily contradict each other but rather illuminate different facets of the same challenge.

My recent post/article on LinkedIn seems to have garnered quite a bit of attention, and several comments that I just can't agree with. 

Over the years, I’ve seen the same objections to model-driven development surface again and again. Someone will say that models are fine for sketches and communication but useless for real implementation, or that once you add all the necessary detail, the model becomes unreadable anyway. Another common claim is that you simply cannot manage models the way you manage source code. I can understand these arguments, but in my opinion, they reflect a partial view of what modeling tools and processes can actually do when you commit to using them seriously.

eVTOL is the buzz in the aerospace community. With recent advances and FAA initiatives, this technology finally seems ready to take off.  (groan)