Archive

Engineering

Building Things

We could describe my whole career as one of building things.

Early on, these things included software, hardware and tech products such as fax servers, compute clusters, compilers, interpreters, network systems, operating systems, development languages, applications, databases, and so on.

Later, things morphed to building teams, communities, software development and delivery groups, business units and tech companies.

Most recently, the things I build have morphed again, into techniques, approaches, tools and know-how applicable to building things.

Learnings

This post is mainly concerned with sharing some of the insights I’ve gleaned over the years. Insights into effective ways of building things:

Purpose

When embarking on building a new thing, I choose to dwell for a while on the purpose of the thing I’m building: Who’s it for? What will they use it for? How will they use it? What needs do they have that this thing willl address?

Needs

What does the Needsscape look like? How can we anticipate it changing over time? And how will we monitor and respond to those changes?

Intentionality

Doing things with a clear understnading of where those things fit in the scheme of things. Rather than just spinning the wheels for the sake of feeling busy.

Quality

Answer the question: “How will we ensure that what we’re building manifests the quality/qualities needed by all the Folks That Matter?

Risks

Manage all key risks facing us in bulding the thing (and in deploying, using it too). See Tom Gilb’s “All Holes In The Boat” principle (any one key risk can sink the whole effort).

Incrementality

Build things in small increments. Get regular feedback from all the Folks That Matter, early and often. Whilst continually remaining open to the system-wide impact of what’s being built.

Clarity of Communication

One can never have too much communication. One can never have too much clarity of communication. I prefer to use Quanitification as the means to improving clarity of communication.

Make Things Visible

Particularly with the kinds of things I’ve been building over the years, things nebuluous and more or less invisible most of the time, it helps to find ways to make e.g. progress visible and clearly understandable to all the Folks That Matter.

PDCA

Often called the Shewhart Cycle or Deming Cycle. PDCA (Plan-Do-Check-Act) offers a conceptual framework for building things:

  • Plan what we’re going to do in the next days or weeks.
  • Do stuff according to that plan.
  • Check how well we did stuff (identify shortcomings)
  • Act to address some shortcomings in our doing, so that the next cycle’s doing goes better.

Ownership

Deming banged on about the necessity for people to have pride in what they do. I find pride is enhanced through people feeling they own what they’re building.

Build Less

Build as little a possible. With the lowest tech possible. Commensurate with meeting folks’ needs. Remember YAGNI.

Summary

I don’t expect the above list to be of much use to anyone. Because, normative learning. C’est la vie.

– Bob

Who’s Delusional?

When it comes to organising the development of software, someone’s delusional.

Maybe it’s me. Despite proving my philosopy and practical apprioach (Quintessence), honed over nearly 30 years of real-world experience.

Maybe it’s you. Clinging to your outdated and unproducive approaches, be they waterfall (batch and queue), or Agile.

Maybe it’s the managers and executives. Doing the same thing year in and year out, expecting different results.

Maybe it’s all of us.

How do you see it?

– Bob

Tarred With the Brush of Excellence

I note a widespread aversion to the idea of “doing things properly”. Not just in the software industry, but also in wider society.

I’m not going to define what “properly” for software development looks like – although I have done so at length in my latest book “Quintessence”.

It’s as if people associate excellence (doing things properly) with higher costs, more effort, and a likely higher boredom factor. 

Whence these associations, I wonder? In my mind, doing things properly implies lower costs, less effort, and more joy in the doing. If not, then how could we describe it as “properly”?

How about you? What’s you take on folks’ responses to “excellence” and the idea of doing things properly?

– Bob

Further Reading

Peters, T.J. and Waterman, R.H. (1982). In Search of Excellence: Lessons from America’s Best-run Companies.  Profile Books.

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub).

It’s not that we don’t know how to design, build and deliver software solutions reliably, predictably and on time. It’s just that those involved don’t want the bother of doing things properly. It’s much easier and more comfortable to just futz around. There’s always sufficient budget to not have to worry about the economics of software production. And lives are cheap.

Quintessence First Version Now Available

The first release version of my new book “Quintessence” is now available for purchase on LeanPub.

With this book I’m rewriting the whole field of software development management. About time, you might say. :}

This version is some 8% complete. I’ll be adding to it progressively over the next few weeks and months. I invite your early comments, suggestions and questions.

– Bob

I find it risible that many software groups refer to themselves as “engineers” and to what they do as “engineering”, when they have no idea what “engineering” actually entails. And in particular, when they make no effort to assess and control software risks (development risks and product risks, both).

See also:

Jones, C. (1994). Assessment and Control of Software Risks. Yourdon Press.

Koen, B. V. (2003). Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving. Oxford University Press.

Demarco, T. & Lister, T. R. (2003). Waltzing With Bears: Managing Risk on Software Projects. Dorset House Pub.

Announcement: New book “Quintessence” In The Works

I’ve just published the Leanpub placeholder for my next book: “Quintessence”. First iteration (likely, 8% complete) will be published soonest!

I’d be delighted if you’d visit the page and express your interest!

– Bob

We might forgive junior software engineers (a.k.a. junior developers) for being ignorant of many things. The field of software engineering is both broad and deep, and it takes many years to come up to speed in all necessary aspects. Indeed, I have seen many engineers with even 10+ years experience having major blind spots and shortfalls in their knowledge. Are the latter “senior engineers”? Many of them bear this title. Outwith my issues about titles, I posit that there are numerous topics, mastery of which is require to fairly assume the title of “senior engineer” (hint: coding skills are but one of some fifteen or twenty such topics).

See also: Scope Of Ignorance

The Inklings

In a previous life, I was charge with leading a whole passel of software and product developers. To help create an environment where they might wish to up their game, I proposed and launched a new community called “The Inklings”. I attach the proposal and launch announcement hereunder, for your delectation/misery.

Proposal

Inklings Proposal

Launch Announcement

Inklings Launch Announcement

NB These two documents have been edited/redacted/dates and names changed, to protect the innocent.

If you’re wondering how it went: I left the company shortly after, and no one took it forward.

– Bob

“In reality, the Western way of managing is still based on the principles of Scientific Management where the goals of management is control and compliance to rigorous processes. The Toyota paradigm is much different; it is based on ongoing learning, capturing the learning for wide reuse, and continually improving the knowledge across generations of products. To do this takes a lot of management understanding and commitment to guide the change.”

~ Michael Kennedy

Excerpted from: Learning-First Product Development: An Interview With Michael Kennedy

%d bloggers like this: