Archive

Posts Tagged ‘linkedin’

Result-Focused, Or State-Focused?

April 23, 2014 Leave a comment

As I continue to explore/evaluate the relevance of the SEMAT Kernel to the future of software engineering, I’m finding that I’m liking it less and less. (For a quick introduction to the SEMAT Kernel, please go read this post, “Revolution, Or Malarkey?“, and then return back here if you’re still interested in what BD00 has to say.)

One of the principal creators of the SEMAT movement, Ivar Jacobson, subjectively asserts that:

“…using the SEMAT kernel to drive team behavior makes the team result focused instead of document driven or activity centric.” – Ivar Jacobson

Using the patented BD00 method of distorted analysis, let’s explore this bold proclamation further.

In the current definition of the SEMAT kernel, each of the seven top-level alphas in the SEMAT Kernel has a state whose value at any given moment is determined by the sub-states of a set of criteria items in a checklist. In addition, each sub-alpha itself has a checklist-determined state.

“Each state has a checklist that specifies the criteria needed to reach the state. It is these states that make the kernel actionable and enable it to guide the behavior of software development teams.” –  “The Essence Of Software Engineering

SEMAT Checklists

So, let’s look at some numbers for a small, hypothetical, SEMAT-based project. Assume the following definition of our project:

  • 7 Alphas
  • Each alpha has 3 Sub-Alphas
  • Each checklist has 5 Items

With these metrics characterizing our project, we need to continuously track/update:

  • 7 alpha states
  • 7 * 3 = 21 Sub-alpha states
  • 7 * 3 * 5 = 105 checklist item states

Man, that’s a lotto states for our relatively small, 21 sub-alpha project, no? It seems like the SEMAT team could be spending a lot of time in a state of confusion updating the checklist document(s) that dynamically track the state values. Thus,

“…using the SEMAT kernel to drive team behavior makes the team state focused instead of result focused.” – BD00

Unless result == state, Ivar may be mistaken.

Don’t Panic!


The fourth edition of “The C++ Programming Language” weighs in at 1346 pages and 44 chapters allocated over four partitions. The end of each chapter provides a list of advisory items – yielding a grand total of 699 nuggets of general programming and C++ specific wisdom for the reader to ponder.

TCPPL4

The figure below shows a breakdown of the behemoth book’s table of contents. The number of advisories provided in each chapter and each partition are shown on the right side.

TCPPL4 Advice

As a temporary excursion from reading and studying and writing exploratory snippets of C++11 code, I went through all 699 items and plucked out a subset of the tidbits I found most useful. Of course, your personal list would no doubt turn out differently.

Fave List

Even though it’s not on my list, my absolute favorite item of advice is the first one presented at the end of chapter 2:

dont panic

D’oh! Wanna guess at how much time is needed for all to become clear? Maybe Malcolm Gladwell‘s famous “10,000 hours” isn’t enough? But that’s why I love C++. It provides an endlessly rich and deep opportunity for learning.

Posing For The Camera


Posers

That tweet was triggered by this exchange within the confines of one of the C++ LinkedIn.com  groups:

Poser Example

Now granted, BD00 may come across as being a poser to some/many, but he actually tries to fend off the strong, innate desire to impress others with his self-proclaimed “expertise“. Of course, as the content of this blog confirms, he often fails miserably. How about you? How often do you find yourself posing for the camera?

Categories: miscellaneous Tags: , ,

What Is It?

June 3, 2013 2 comments

Ok dear reader, it’s quiz time! How does an enduring album come into the world? How does a revered painting emerge into being? How does a beloved novel spring forth? Please describe the “Process” in your own words….

Abstract Concrete

Revolution, Or Malarkey?

May 14, 2013 4 comments

BD00 has been following the development of Ivar Jacobson et al’s SEMAT (Software Engineering Method And Theory) work for a while now. He hasn’t decided whether it’s a revolutionary way of thinking about software development or a bunch of pseudo-academic malarkey designed to add funds to the pecuniary coffers of its creators (like the late Watts Humphrey’s, SEI-backed, PSP/TSP?).

To give you (and BD00!) an introductory understanding of SEMAT basics, he’s decided to write about it in this post. The description that follows is an extracted interpretation of SEMAT from Scott Ambler‘s interview of Ivar:  “The Essence of Software Engineering: An Interview with Ivar Jacobson”.

As the figure below shows, the “kernel” is the key concept upon which SEMAT is founded (note that all the boasts, uh, BD00 means, sentences, in the graphic are from Ivar himself).

In its current incarnation, the SEMAT kernel is comprised of seven, fundamental, widely agreed-on “alphas“. Each alpha has a measurable “state” (determined by checklist) at any time during a development endeavor.

SEMAT Kernel

At the next lower level of detail, SEMAT alphas are decomposed into stateful sub-alphas as necessary:

SEMAT Sub-Alphas

As the diagram below attempts to illustrate, the SEMAT kernel and its seven alphas were derived from the common methods available within many existing methodologies (only a few representative methods are shown).

Agile Over SEMAT

In the eyes of a SEMATian, the vision for the future of software development is that customized methods will be derived from the standardized (via the OMG!) kernel’s alphas, sub-alphas, and a library of modular “practices“. Everyone will evolve to speak the SEMAT lingo and everything will be peachy keen: we’ll get more high quality software developed on time and under budget.

SEMAT Practices

OK, now that he’s done writing about it, BD00 has made an initial assessment of the SEMAT: it is a bunch of well-intended malarkey that smacks of Utopian PSP/TSP bravado. SEMAT has some good ideas and it may enjoy a temporary rise in popularity, but it will fall out of favor when the next big silver bullet surfaces – because it won’t deliver what it promises on a grand scale. Of course, like other methodology proponents, SEMAT’s advocates will tout its successes and remain silent about its failures. “If you’re not succeeding, then you’re doing it wrong and you need to hire me/us to help you out.

But wait! BD00 has been wrong so many times before that he can’t remember the last time he was right. So, do your own research, form an opinion, and please report it back here. What do you think the future holds for SEMAT?

They Do Us!

Which Path?

April 26, 2013 7 comments

Please peruse the graphic below and then answer these questions for BD00: Is it a forgone conclusion that object-oriented development is the higher quality path from requirements to source code for all software-intensive applications? Has object-oriented development transitioned over time from a heresy into a dogma?

SA vs OO

With the rising demand for more scaleable, distributed, fault-tolerant, concurrent systems and the continuing maturation of functional languages (founded on immutability, statelessness, message-passing (e.g. Erlang, Scala)), choosing between object-oriented and function-oriented technical approaches may be more important for success than choosing between agile development methodologies.

Follow

Get every new post delivered to your Inbox.

Join 469 other followers

%d bloggers like this: