Perfect And Real

July 9, 2016 2 comments

In the perfect Scrum world, software is developed over time in fixed-size (ΔT) time boxes where all the work planned for the sprint is completed within the timebox. Typically ΔT is chosen to be 2 or 4 weeks.

perfect scrum

If all the tasks allocated to a sprint during the planning meeting are accurately estimated (which never happens), and all the tasks are independent (which never happens), and any developer can perform any task at the same efficiency as any other developer (which never happens), then bingo – we have a perfect Scrum world.

However, in the real world (Scrum or non-Scrum), some (most?) tasks are interdependent, some tasks are underestimated, and some tasks are overestimated:

Real Scrum

Thus, specifying a fixed ΔT timebox size for every single sprint throughout the effort may not be a wise decision. Or is it?

Categories: management Tags: ,

To The Moon Alice!

June 18, 2016 2 comments

Using the information below as a reference point,

goldandbondmarketcaps

let’s do some rounding and truncating and assume the following:

  • The total market capitalization of gold is $10T
  • The total market capitalization of negative interest bonds is $10T

With 15M BTC in circulation, the current market capitalization of Bitcoin is around $10B. If (when?) Bitcoin eventually manages to steal just 10% of the market capitalization from each of those two assets, its market cap would balloon to $2T, resulting in a gain of 200X. Yepp, that’s “X” and not “%”.

Bitcoin’s current price per USD is around $750. Multiplying this price by 200 yields a new price of $150,000 per BTC.

Of course, the BTC price could collapse to $0 at any point in time. However, since its launch in 2009, it has been declared “dead” by various experts over 106 times – and still counting.

btcobits

If you’ve got $750 of play money laying around, fuggedaboud searching for the next Amazon/Apple/Google/Netflix to invest in and hoping that the esteemed management of your new investment doesn’t fuck up for a decade. Consider doing the following instead:

  1. Opening an account on a reputable Bitcoin exchange (I use coinbase.com (USD-to-BTC exchange fee of 1%)).
  2. Buying 1 Bitcoin
  3. Becoming your own bank and immediately moving your 1 BTC out of your online exchange wallet and into your own PC-based wallet (I use Electrum), or mobile phone-based wallet (I use Blockchain), or hardware-based wallet (I use Trezor).

If BTC collapses or (more likely) you screw up taking full personal control over your BTC, your maximum loss will be $750. However, your upside is “to the moon Alice!“.

alice

Categories: bitcoin Tags: , , ,

A New Alternative

June 17, 2016 2 comments

Humor me for a moment and assume that you knew your country’s fiat currency was going to collapse soon.

USDcollapse

The traditional response to such an impending calamity would be to exchange all your fiat currency for a precious metal, especially gold.

An alternative way to preserve your wealth in an apocalyptic world would be to exchange your fiat currency for a cryptocurrency, of which Bitcoin is king. If you didn’t take any action whatsoever, your accumulated wealth would disappear in a hyperinflationaty crisis – either slowly or instantaneously. Just ask the citizens of Nigeria, Venezuela, Brazil, Argentina, Zimbabwe or any other country with incompetent, corrupt governments that rack up huge debts and continuously devalue their currency.

The problems with holding physical gold bars are: storing them, transporting them, defending them against theft, and accurately dividing them up to pay others for food/services.

With Bitcoin and other cryptocurrencies, these problems are almost non-existent. You can store the majority of your cryptocoins in a tiny, easy to hide, encrypted and password protected, hardware wallet (Trezor, Ledger, Keepkey, etc). You can periodically transfer small mounts to your cell phone wallet to pay for food and other daily expenses.

bitcoinorgold

So, what would YOU do if you knew for certain that your national currency was about to go poof? Isn’t it about time you started learning about the future of money, cryptocurrencies? I suggest you start with YouTube. There are tons of introductory Bitcoin videos to watch.

Front And Back

In response to my previous post, Glen Alleman pointed out that for large system development projects, the technical plan must be preceded by a higher level, coarser, activity. Glen is right.

Senior analysts and architects don’t just sit down and start designing the technical plan from scratch. They work with experienced, knowledgeable customers to develop, define, and document the capabilities that the system must satisfy in order to solve their problem. Thus, I’ve augmented my diagram to show this important activity:

FrontAndBack

We’re not done yet. There is still (at least) one more front end activity missing from the diagram: the problem definition phase:

ProblemDefinition

So, what precedes the problem definition phase? The pain of problem discovery….

ProblemDiscovery

The Agile community does a great job of defining how the back end should be managed for cost-effective product development, but IMO they are mostly silent on the much-more-important, fuzzy, front end.

What Happened Before The First Product Backlog?

Some people like to ask: “What happened before the big bang?“. Being a geeko-nerd, I like to ask: “What happened before the first product backlog?”.

The missing artifact

Regarding agile framework definitions, IMO, Scrum has the most well-documented and coherent definition of the bunch. However, since it remains silent on the issue, I still wonder: “WTF happens before the first product backlog?”.

For innately complex systems requiring a large amount of coordinated effort, here’s what I think should happen:

  • A small group of senior domain analysts and system architects should spend a fair amount of un-pressured time to develop and document the high level, technical blueprints (structures + behaviors) for what needs to be built.
  • The authoring group should disseminate and educate the rest of the development team on the technical vision.
  • The team should populate and iterate on the first version of the product backlog.
  • The team should decide on, and put in place, the development toolset and infrastructure that will be used to develop and test the system throughout the effort.
  • The team, including the technical authors, should start incrementally and iteratively building the system – revisiting/updating the plans/product backlog frequently when new knowledge is discovered as the project moves forward.

What do YOU think should happen before the first product backlog?

Is There REALLY Such A Thing?

A Loss Of Heart

Zero Out Of Ten

May 27, 2016 4 comments

In a recent talk at Cambridge University, Bjarne Stroustrup presented this slide to his audience:

StroustrupTop10List

Although lots of hard work has been performed by some very smart people over the years in developing these features, Mr. Stroustrup (sadly) went on to say that none of them will be present in the formal C++17 specification. The last sentence on the slide succinctly summarizes why.

Categories: C++17 Tags: ,

M Of N Fault Detection

Let’s say that, for safety reasons, you need to monitor the voltage (or some other dynamically changing physical attribute) of a safety-critical piece of equipment and either shut it down automatically and/or notify someone in the event of a “fault“.

FaultDetection

The figure below drills into the next level of detail of the Fault Detector. First, the analog input signal is digitized every ΔT seconds and then the samples are processed by an “M of N Detector”.

Fault Detector

The logic implemented in the Detector is as follows:

MofNLogic

Instead of “crying wolf” and declaring a fault each time the threshold is crossed (M == N == 1), the detector, by providing the user with the ability to choose the values of M and N, provides the capability to smooth out spurious threshold crossings.

The next figure shows an example input sequence and the detector output for two configurations: (M == N == 4) and (M == 2, N == 4).

FDExamples

Finally, here’s a c++ implementation of an M of N Detector:

#ifndef MOFNDETECTOR_H_
#define MOFNDETECTOR_H_

#include <cstdint>
#include <deque>

class MofNDetector {
public:
  MofNDetector(double threshold, int32_t M, int32_t N) :
    _threshold(threshold), _M(M), _N(N) {
    reset();
  }

  bool detectFault(double sample) {

    if (sample > _threshold)
      ++_numCrossings;

    //Add our newest sample to the history
    if(sample > _threshold)
      _lastNSamples.push_back(true);
    else
      _lastNSamples.push_back(false);

    //Do we have enough history yet?
    if(static_cast<int32_t>(_lastNSamples.size()) < _N) {
      return false;
    }

    bool retVal{};
    if(_numCrossings >= _M)
      retVal = true;

    //Get rid of the oldest sample
    //to make room for the next one
    if(_lastNSamples.front() == true)
      --_numCrossings;

    _lastNSamples.pop_front();

    return retVal;
  }

  void reset() {
    _lastNSamples.clear();
    _numCrossings =0;
  }

private:
  int32_t _numCrossings;
  double _threshold;
  int32_t _M;
  int32_t _N;
  std::deque<bool> _lastNSamples{};

};

#endif /* MOFNDETECTOR_H_ */
Categories: C++, technical Tags: ,

A Quarter Of An Hour

May 19, 2016 2 comments

Looky here at what someone I know sent me:

PointTwoFive

This person is working on a project in which management requires time tracking in .25 hour increments. On some days, that poor sap and her teammates spend at least that much time at the end of the day aggregating and entering their time into their formal timesheets.

Humorously, those in charge of running the project have no qualms about promoting their process as “agile“.

I can’t know for sure, but I speculate that the practice of micromanagement cloaked under the veil of “agile” is pervasive throughout the software development industry.

Categories: management Tags: ,