Reflective Praxis Thoughts on engineering and software development

Growing Passion

It’s often said that you should do what you love. But in my career I’ve sometimes ended up working on things that didn’t (initially) seem all that exciting, and weren’t exactly (to begin with) “what I loved”. And yet…

Read more...

Enqueuing Embedded Events

Most of my software development career has been in the embedded domain, a subset of software development that sometimes feels like it lags industry trends by a decade or more. One area where embedded has definitely lagged is test-driven development. James Grenning (one of the original signatories of the Agile Manifesto) has been pushing that particular cause for years with mixed success. For the last few years, my former colleague Matt Chernosky has been writing some really useful, practical guides to embedded TDD at electronvector.com. I recently wrote a guest piece for Matt’s blog discussing an architectural pattern for event-based embedded systems that makes embedded TDD a little easier. The core idea is to use an event queue and dispatching event loop to decouple parts of the system from each other. It’s not exactly a novel idea. But it’s one that probably isn’t as widely used in embedded systems as it should be. You can find the whole post (and links to working source code) at http://www.electronvector.com/blog/avoiding-mocks-by-enqueuing-events.

Read more...

Decisions, Decisions

I’ve argued in the past that it’s worth putting some thought into the why behind your design for a software architecture. But while knowing the why at the time is great, it’s even more helpful to be able to remember the why a month or a year later. I was recently reminded of this when I stumbled across Doug Arcuri’s post on the importance of documenting software decisions.

Read more...

How Software Learns

Software development approaches that “embrace change” have become immensely popular over the last couple of decades. Many software developers consciously avoid “Big Design Up Front” in favour of incrementally developing software story-by-story. But the intent to “avoid BDUF” often mutates into an attitude that “if you refactor often enough then a good software architecture will magically just happen”. Architectural planning is seen as something that you do for big static things, like buildings, not for something dynamic, like software. But what if I told you that buildings are a lot more dynamic than you probably think? Can we learn something about software by looking at buildings?

Read more...

Why Think About Software Architecture?

Why do we structure a software design the way we do?

Read more...