Software Development Tools

 A job ad for a software engineer listed the following tools. I'm not familiar with half of them (not even by name).  Writing down the list as I'm curious to do some digging and find out what each are:

• Jenkiins (a continuous integration and deployment framework)
• AWS Cloud
• Azure
• Splunk (for logging and metrics)
• App Dynamics (for loggin and metrics)
• ECS
• Github
• Artifactory
• Kong
• OAuth
• Serverless technologies
• Node.js
• Automation
• Ansible
• Terraform
• Python 
• Java
• Linux
• CloudFormation
• RDS
• PostGresSQL
• NoSQL
• Angular
• ReactJS
• GIT
• Spring Boot

Make Up Your Mind (Chapter 2)

I have quite a number of books in my library, virtually all of them non-fiction. I'm starting to think there's not enough time to read them all. Skimming each one doesn't really help me absorb them, so I thought it might be interesting to explore the books by reading Chapter 2 of each.

Today's book is Make Up Your Mind, by Hal Mooz. The author is well-known in the Systems Engineering community as co-author of Visualizing Project Management, and Communicating Project Management.

Chapter 2 of this book is "Decision Fundamentals for Thinking Clearly". It's a short chapter and touches very briefly several topics relevant to thinking clearly.

We get a reminder that decision rigor is 'driven by the fear of a negative outcome'. This is something we all instinctly already know. We become more anxious when the decision has serious consequences (eg, which univerisity to go to), and are rightly less rigorous when the consequences are not serious (eg, what to have for lunch).

An interesting paragraph is on when do we actually 'make' a decision? Does deciding one way or another constitute making the decision or is further action required?  Some decision experts say you make the decision when you irrevocably allocate resources. (I had not heard of this before.  I think it's a good criteria). The author argues against it because it fails in some cases. His example is the decision to lose weight and deciding to eat less. Contrary to this criteria, the decider has actually decided NOT to allocate resources (food).

The author defines a good decision as 'applying informed judgment based on relevant facts and quality ethics to select an alternative and act on it'.

A short paragraph reminds us that the outcome does not define whether a decision is good or not. This is pretty much an obligatory topic in any decision making text.  Another paragraph covers another obligatory topic -- the fallacy of sunk costs.

Mooz introduces a concept new to me: 'Cost / Price of Indifference'. It is the purchase price at which you don't care (emotionally) whether you get the goods or not. He suggests this is a time saving concept when purchasing or selling anything. Rather than agonising hours and hours over how much to bid, just bid at this price.  He did not discuss this in the context of buying stock market shares. I think that will be interesting to consider. 

There are two stages to decision-making. The first is Decision Preparation. This is about getting the decision statement right, setting up the decision type frame, and the decision solution frame correct.  The second stage Deciding, which is about the act of selecting from the alternatives that were set up in the decision solution frame.  (The author didn't mention this, but I recognise this 2-stage framework as  classically systems engineering).

Other short topics covered is the decision maker's viewpoint, decision fitness, and decision fatigue. Decision Fitness is another concept I had not heard of before. This is a concept about the fitness of the person making the decision. They must be proficient at the following skills:

• Specifying the decision and context
• Determining the decision type
• Creating the decision type frame
• Developing the decision solution frame
• Creating viable alternatives
• Identifying and geting the comparative information
• Knowledgeably selecting the right judgment basis
• Skillfully applying the appropriate judgement process

A quick glance at the table of contents reveals many of these topics are covered in the rest of the book. 

This is a short book. At only 166 pages and with larger than normal font, it is misleadingly light-looking. Judging from the concepts introduced in the Chapter 2, it seems like a concept-heavy, deeply useful text.  Just considering the list of skills listed in order to be 'decision fit' shows you how much is required to be a good decision maker.  I'm not sure this thin book will be able to cover what is required to be decision fit, but if it gives exposure and awareness of the concepts, it will be worth further study. 

Agile vs Waterfall

Often heard: "What you experienced was not true Agile."

Never heard:"What you experienced was not true Waterfall."

Not So SMART Objectives

In a VUCA world, objectives must be SMART:

S – Subjective

M – Machiavellian

A – Adjustable

R – Reactionary

T - Tentative

The Real FR vs NFR Requirements

Any professional working with requirements is familiar with the abbreviations FR (Functional Requirements) and NFR (Non-Functional Requirements). This categorisation attempts to distinguish one type of requirement from the other. It's an unfortunate exercise to separate them so distinctly because FRs often need to be described with their accompanying NFRs, while NFRs are often met by implementing a set of FRs.

However, we can reuse the FR vs NFR distinction in some other ways. Proposed below is a list of the more important ones:

Fictional vs Non-Fictional Requirements – Fictional requirements are not really requirements. They are designs, solutions, or wishes masquerading as requirements.  Non-fictional requirements are real requirements.

Factional vs Non-Factional Requirements – Factional requirements are those pushed for by only a certain set of stakeholders. Other stakeholders couldn’t care less about these. Non-factional requirements are required by the system and transcend individual factions.

Frictional vs Non-Frictional Requirements – Frictional requirements are contentious, either to some stakeholders or to other requirements. They also cause friction in the system development by causing the majority of the delays. 

Fallacious vs Non-Fallacious – Fallacious requirements are requirements that are properly written (they are Non-Fictional), but aren’t what is needed. Non-Fallacious requirements are requirements that are needed.

Fundamental vs Non-Fundamental – closely related are Fundamental requirements, which are essential to meeting the objectives. Non-Fundamental requirements are 'nice to haves'. Ironically, building only Non-Fundamental requirements does not result in a nice system.

Function vs Non-Function – Function requirements are about what the system needs the user to be able to do (‘The user must be able to cancel a transaction’). The user is replaced if they cannot perform the function. Non-function refers to user attributes and capabilities (‘The user must have the ability to view the most recent transactions' -- perhaps by possessing SQL skills?)

Familiar vs Non-Familiar – requirements that are common to many systems. These include management reports, etc. Non-familiar requirements are those that haven't appeared before in the project's collective experience.

Favourite vs Non-Favourite – Favourite requirements are flashy requirements sponsored by someone. They tend to be given attention. Non-Favourites languish or are implemented and tested perfunctorily. No one notices if they run away.

Falsifiable vs Non-Falsifiable – Falsifiable requirements are those that can be shown to not exist. Non-Falsifiable requirements cannot be proven to have been met. A quintessential example being ‘The system must be user friendly’. 

Fat vs Non-Fat – Fat requirements are a clump of requirements stated as one single requirement, often with multiple adjectives.  They tend to clog the process. Too many can result in a project heart attack. Non-Fat requirements are singular, and are processed through without harmful effect.

Fiscal vs Non-Fiscal – Fiscal requirements relate to cost ( ‘The solution shall not cost more than $X per transaction’)

Filial vs Non-Filial – Filial requirements are those that can be traced to a parent requirement. They show respect, and obedience, and conform to their parents wishes. Non-Filial requirements are either orphans or contradict their parent requirements. They cause family infighting and should be made to either conform, or else be cut off from family tree.

Fecund vs Non-Fecund Requirements - Fecund requirements are prone to keep popping out new requirements -- annoying, smelly, little new requirements that need lots of care and feeding.

Book Review: Breaking the Code of Project Management

Breaking the Code of Project Management
Alexander Laufer

The genesis of this book come from Laufer’s observation that traditional project management principles need overhauling.  He argues that the growing realisation of the power of empowerment, the poor historical record of project management, the flawed foundation of a major project management tool (PERT), and ‘emerging paradigms’ in research and practice require a new investigation into what is needed to ensure project success.

Laufer is big on using stories as a means of learning and presents his reasons why.  The book brims with stories.

It gave me some discomfort when Laufer referred to the ‘Agile method’ as a ‘project management approach’, given its limited focus on product development (primarily software products).  He also makes the mistake of referring to the ‘four values’ (a pet peeve of mine).

No project management tools appear in this book.  You won’t find discussions of the WBS, PBS, Gantt Charts.  The focus is on what it takes to deliver projects successfully.

Laufer concentrates on what he calls ‘Results-Focused Leadership’, a framework of guiding principles, colour-coded for vividness: yellow for the spirit of will to win, green for planning, brown for implementation, red for people and organisations, and grey for communications.

Recommendation: A practical book on how to deliver projects, yet very different from the standard project management books which cover the tools and principles of project management.  It almost ignores traditional project management.

Book Review: The Power of Doing Less: Why Time Management Courses Don't Work And How To Spend Your Precious Life On The Things That Really Matter

Fergus O’Connell claims that the real reason why time management courses fail is because ironically, they try to teach time management.  This is the wrong approach, says the author. What they should be teaching instead is that people should aim to do less work. This is the aim of this book.

A major portion of the book is about convincing the reader that the right strategy is to reduce the work you need to do: decide which ones you need to do and which ones you don’t need to do.
 
The rest of the book provides quick and easy techniques to drop unnecessary work, and prevent new work from coming to you, or back to you.

Apart from the main point about reducing what you need to do, this is a basic work on regaining more time for yourself.