Pages

Tuesday, 12 January 2021

Tom Gilb on Systems Enterprise Architecture

A few days ago my friend Tom Gilb asked me to comment on his new book on SEA (Systems Enterprise Architecture).

I've followed Tom's work since he wrote an inspirational and iconoclastic column in Computer Weekly back in the 1980s. 

Tom has always been sceptical of claims made in IT without quantified evidence. Early in SEA he tells us 'There comes a threshold of complexity in all disciplines where quantification becomes a necessary tool. The time has come for IT Enterprise Architecture to really make use of quantification, and not just talk about doing it.'

He's right, and many traditional IT departments need to mend their ways, but I think Tom underestimates the extent to which the Smart Kids already practice what he preaches. They know that gives them a competitive edge, and for that reason they tend not to broadcast what they do. I'm lucky enough to know a few of them, so I get to hear a little of what they are up to and how they do it.

The TDD world has always placed a lot of emphasis on verifying functional correctness through automated testing. Tom has always placed additional emphasis on the (non-functional) qualities of software: reliability, usability, performance, security and so forth. These are vital to the delivery of business value but they need much more skill to quantify and test. That's why most requirements documents have paid lip service to the qualities without specifying quantified goals and the means of measurement.

While traditional IT often fails in that respect, most young, successful cloud-based businesses live or die by the efficiency, availability, usability, and reliability of their software. They measure these qualities in real-time and deploy changes in real-time to fix problems when they detect them. I'm sure they could do better, and I'm sure that Tom's book could help them to do that, but they are already way ahead of traditional IT.

Tom's expertise can help those who are already doing the right things; for others, his approach would be a game-changer. Sadly I fear few will take advantage of it. They would have to change from being an expert in the old ways to being a novice in the new, and that's always a difficult thing to do.

If you'd like to take a look at the SEA book, you can download a free PDF here:

https://www.dropbox.com/sh/1t8uwy9xxu52tl5/AACYDtWQ0EDCTZ6D-pJIaSM4a?dl=0



Friday, 16 October 2020

Document breadboard builds by writing Python code

In my last post I mentioned that I was using breadboarder - a Python program that eases the pain of documenting breadboard-based projects.

You write a descriptiopn of your project using a Python-based DSL - a domain-specific language.

It lets you explain what wire or component to add to the breadboard, and where to connect it.

You write code like this:


And it generates markdown and png files which render like this:



It saves hours of layout, you can build complex projects out of simple ones, and everything is under source control.

I need to improve the documentation but breadboarder is on GitHub.


Wednesday, 14 October 2020

Fault-finding breadboarded circuits - a tale from the trenches

blobstar
Yesterday I destroyed an Atmel ATMega328 chip. (That's the chip at the heart of the Arduino.)

The Atmel chips are very well designed, and it's really hard to damage them, but I've managed it twice in the last decade. Yesterday's episode was due to a mistake in wiring up an Arduino clone that I've been building on a breadboard.

The clone is a descendant of Cefn Hoyle's excellent Shrimp design. I decided to build an alternative version which could be programmed using an FTDI cable and made permanent using an Adafruit perma-proto board.

The correct layout (shown above) is easy to follow, but my ageing eyes led me to connect two of the power wires to the wrong pins. When I powered up the board using an FTDI cable the LED didn't blink and I knew something was wrong.

But what?

A simple approach to problem-solving

When something stops working, you focus on what's changed. When you have two versions of something, only one of which works, you focus on the difference.

In my case I had a working version of the design on an Adafruit permo-proto board. When I compared the bread-boarded version with the board that worked I realised the mistake I'd made. I fixed the wiring and tried again.

The bread-boarded version still didn't work.

I rechecked the wiring and convinced myself that there were only minor differences between the bread-boarded and soldered versions. The bread-boarded version uses a crystal and I'd omitted a couple of tiny capacitors that aren't normally necessary, so I added them. Still no joy.

By now the only significant difference between the circuits was the physical chips.

I swapped the chip from the known-good board into the breadboard, powered it up, and...

Success


The board worked!

Here's the perma-proto version blinking as it should.

Clearly, my earlier wiring mistake had fried the ATMega chip.  Once I'd replaced it both versions worked.

I'm documenting the breadboard version for use in an updated version of my e-book Making the Shrimp. I'm using a neat piece of software called breadboarder.

Breadboarder lets you describe a circuit using a simple Python-based DSL (Domain Specific Language). It generates an SVG diagram and step-by-step instructions in plain English.

I'll describe breadboarder in a bit more detail in my next post.