Scanning over Alvin Ashcraft’s excellent Morning Dew (a must read for .Net devs as is Chris Alcock’s Morning Brew), I came across a short article from Richard Carr on writing Fixed Width Data Files using C#.

Richard creates a class that inherits from StreamWriter, and all-in it’s just over 50 lines of idiomatic C# code:

using System;
using System.IO;
using System.Text;

public class FixedWidthWriter : StreamWriter
{
    public int[] Widths { get; set; }

    public char NonDataCharacter { get; set; }

    public FixedWidthWriter(

          int[] widths, string path, bool append, Encoding encoding)
        : base(path, append, encoding)
    {
        NonDataCharacter = ' ';
        Widths = widths;
    }

    public FixedWidthWriter(int[] widths, string file)
        : this(widths, file, false, Encoding.UTF8) { }

    public FixedWidthWriter(int[] widths, string file, bool append)
        : this(widths, file, append, Encoding.UTF8) { }

    public void WriteLine(string[] data)
    {
        if (data.Length > Widths.Length)
            throw new 

                InvalidOperationException("The data has too many elements.");

        for (int i = 0; i < data.Length; i++)
        {
            WriteField(data[i], Widths[i]);
        }
        WriteLine();
    }

    private void WriteField(string datum, int width)
    {
        char[] characters = datum.ToCharArray();
        if (characters.Length > width)
        {
            Write(characters, 0, width);
        }
        else
        {
            Write(characters);
            Write(new string(NonDataCharacter, width - characters.Length));
        }
    }
}

As you’d probably guess the same functionality takes half the lines to express in F#:

open System
open System.IO
open System.Text

type FixedWidthWriter(widths:int[], path:string, append, encoding) =
    inherit StreamWriter(path, append, encoding)
    member val Widths = widths with get, set
    member val NonDataCharacter = ' '  with get, set
    new(widths, file) = 
        new FixedWidthWriter(widths, file, false, Encoding.UTF8)
    new(widths, file, append) =
        new FixedWidthWriter(widths, file, append, Encoding.UTF8)
    member this.WriteLine(data:string[]) =
        if data.Length > this.Widths.Length
        then invalidOp "The data has too many elements."
        for i = 0 to data.Length-1 do      
            this.WriteField(data.[i], this.Widths.[i])
        base.WriteLine()
    member private this.WriteField(datum:string, width) =
        let xs = datum.ToCharArray()
        if xs.Length > width
        then base.Write(xs, 0, width)
        else        
            base.Write(xs)
            base.Write(String(this.NonDataCharacter, width - xs.Length))

The C# implementation uses classes and inheritance. In F# we’d typically favour composition over inheritance and start with the simplest possible thing that works, which in this case is a function that takes a file path, widths and the lines to write:

let WriteFixedWidth (path:string) (widths:int[]) (lines:string[] seq) =
    let pad = ' '
    use stream = new StreamWriter(path)
    let WriteField (datum:string) width =
        let xs = datum.ToCharArray()
        if xs.Length > width
        then stream.Write(xs, 0, width)
        else        
            stream.Write(xs)
            stream.Write(String(pad, width - xs.Length))
    for line in lines do
        for i = 0 to widths.Length-1 do 
            WriteField line.[i] widths.[i]
        stream.WriteLine()

The function is about half the size again and more closely follows YAGNI. To test it we can simply write:

let widths = [|20; 7; 6|]
[
[|"Company"; "Spend"; "Rating"|]
[|"Quality Foods Limited"; "1000000"; "Gold"|]
[|"The Pieman"; "50000"; "Silver"|]
[|"Bill's Fruit and Veg"; "10000"; "Bronze"|]
]
|> WriteFixedWidth "c:\\test.txt" widths

Does the language you chose make a difference?

When writing software we’re working at two levels:

1. Creating an executable specification of exactly what we want the machine to do
2. Creating a living document that describes the intent of what we want the machine to do, to be read by humans

The first part is the easy part, the second part takes a lifetime to master. I read a really great post today pointing out signs that you’re a bad programmer. Whether you’re a bad programmer or just inexperienced, I think the biggest barrier is being able to quickly and accurately visualize code. You need to visualize what the application actually does, what happens at runtime; but all your IDE shows you is the raw, static, source code. From this static view of the world you have to infer the runtime behaviour, you have to infer the actual shape of the application and the patterns of interaction; while closely related, the two are separate. Given just source code, you need to be able to visualize what code does.

What does it mean to visualize code? At the simplest level, it’s understanding what individual statements do.

string a = "Hello":
string b = "world";
a = b;

It might sound trivial, but the first necessary step is being able to quickly parse code and mentally step through what will happen. First for basic statements, then for code that iterates:

while (stack.Count() > 1)
{
    var operation = stack.Pop() as IOperation;
    var result = operation.Execute(stack.Pop(), stack.Pop());
    stack.Push(result);
}

Where you need to understand looping mechanics and mentally model what happens overall not just each iteration. Then you need to be able to parse recursive code:

int Depth(ITreeNode node)
{
    if (node == null)
        return 0;
    return 1 + Math.Max(Depth(node.Left), Depth(node.Right));
}

Which is generally harder for inexperienced programmers to understand and reason about; even though once you’ve learned the pattern it can be clearer and more concise.

Once you’ve mastered how to understand what a single method does, you have to understand how methods become composed together. In the OO world, this means understanding classes and interfaces; it means understanding design patterns; you need to understand how code is grouped together into cohesive, loosely coupled units with clear responsibilities.

For example, the visitor pattern has a certain mental structure – it’s about implementing something akin to a virtual method outside of the class hierarchy; in my mind it factors a set of classes into a set of methods.

public interface IAnimal
{
    void Accept(IAnimalVisitor visitor);
}

public class Dog : IAnimal { ... }
public class Cat : IAnimal { ... }
public class Fox : IAnimal { ... }

public interface IAnimalVisitor
{
    void VisitDog(Dog dog);
    void VisitCat(Cat cat);
    void VisitFox(Fox fox);
}

The first step in reading code is being able to read something like a visitor pattern (assuming you’d never heard of it before) and understand what it does and develop a mental model of what that shape looks like. Then, you can use the term “visitor” in your code and in discussions with colleagues. This shared language is critical when talking about code: it’s not practical to design a system by looking at individual lines of code, we need to be able to draw boxes on a whiteboard and discuss shapes and patterns. This shared mental model is a key part of team design work; we need a shared language that maps to a shared mental model, both of the existing system and of changes we’d like to make.

In large systems this is where a common language is important: if the implementation uses the same terms the domain uses, it becomes simpler to understand how the parts of the system interact. By giving things proper names, the interactions between classes become logical analogues of real-world things – we don’t need to use technical words or made up words that subsequent readers will need to work to understand or learn, someone familiar with the domain will know what the expected interactions are. This makes it easier to build a mental model of the system.

For example, in an online book store, I might have concepts (classes) such as book, customer, shopping basket, postal address. These are all logical real world things with obvious interactions. If I instead named them PurchasableItem, RegisteredUser, OrderItemList and DeliveryIndicationStringList you’d probably struggle to understand how one related to the other. Naming things is hard, but incredibly important – poor naming will make it that much harder to develop a good mental model of how your system works.

Reading code, the necessary precursor to writing code, is all about building a mental model. We’re trying to visualize something that doesn’t exist, by reading lines of text.

JavaScript is a bubble.

Just like the housing bubble.

Just like the .COM bubble.

And just like any bubble, the JavaScript bubble is bound to pop.

Sure, JavaScript is everywhere.  It appears to be growing at a rapid pace.  But I’m willing to bet that we are getting close to a complete reversal that will throw JavaScript down from its throne, shattering its JQuery scepter with it.

JavaScript never really made a comeback

Part of the problem with JavaScript is that it’s propped up on the back of another technology. See, JavaScript itself was rejected long ago. If JavaScript was a wonderful language to develop in, its wonders would have been praised years ago when it was first introduced. But I remember cursing JavaScript 15 years or so ago.  And I wasn’t alone.

Yes, I know it was a dark time, but recall, if you will, your pure hatred for JavaScript.  You know, before it was so cool.

Then how did this ugly wart of a language become so popular?

Well, you see, it was this little library called JQuery. JQuery solved a very real and annoying set of problems that wasn’t around when JavaScript was first invented: manipulating the DOM and making Ajax calls.

JQuery was basically designed to make JavaScript possible to work with. Before JQuery, DOM manipulation and Ajax calls were difficult. After JQuery, they were easy.

So JQuery ended up being this big band-aid that covered up all the ugly JavaScript code you didn’t want to write and made doing what you wanted to do much easier.

You may disagree with me on this point, and you are welcome to do so, but even if JQuery isn’t the reason JavaScript is so hot right now, do you honestly think JavaScript would have become so popular if JQuery never existed?

The problem with JavaScript

I want to love JavaScript. I really do.

I know it doesn’t sound like I do, but just like I can’t make myself like sweet potatoes—even though I know how good they are for me—I can’t like JavaScript.

I’ve tried many things. I’ve put some butter and brown sugar on a freshly baked sweet potato. I’ve doused it with hot sauce. I’ve even pretended it was a regular potato and dressed it up like one. But, the fact remains, I just don’t like sweet potatoes. It’s something in their very nature that I despise.

I’ve tried the same thing with JavaScript. I’ve added libraries that make it much sweeter, like JQuery and Backbone.js. I’ve used tools like CoffeeScript and TypeScript to try and pretend it was a more palatable language. But the fact remains, JavaScript has some things that are fundamentally wrong with it that no amount of covering up or pretending will fix.

If JavaScript wasn’t so ugly at heart, then a book called “JavaScript, The Good Parts,” probably wouldn’t be the #1 best-selling book on Amazon for JavaScript, the #3 best-selling book on web development, and the #4 best-selling book on software development, would it? (Go ahead and check it out for yourself if you don’t believe me.)

I don’t really need to tell you again what is wrong with JavaScript. If you use JavaScript, you know. If you don’t use JavaScript, just search for “why JavaScript sucks” on Google and you’ll get plenty of answers.

The point is, unless we are going to be completely disillusioned about it, we can probably all agree that JavaScript is not the greatest programming language that was ever created, and that it has some glaring weaknesses.

My point is not to bash JavaScript

Before you pitchfork me, I want to clear a few things up.

I don’t hate JavaScript.

I don’t suggest you shun JavaScript and go off with me to a floating island in international waters where we will build a new internet, one that isn’t infected by JavaScript.

I actually use JavaScript.
Not only do I use JavaScript, but I have to use JavaScript and so do you.

And if you are smart and want to have a good career in software development, you’ll take everything I am saying with a grain of salt, knowing that I could be completely wrong.

If you are smart, you won’t just dump JavaScript out the window, betting that it will fail, because it might not. It might grow to become the one universal language that replaces all other programming languages. JSON sempiternus!

But, on the other hand, if you are smart, you won’t put all your eggs in the JavaScript basket either. Even though the world seems bright and cheery for JavaScript developers today, it also seemed equally bright and cheery for Blackberry devs not too long ago. And look how that turned out.

And if you are solely a JavaScript developer or you really like JavaScript, I sincerely don’t mean to offend you, but I offer this piece of advice: You are not the technology you happen to be using.

Trust me, if you’re a good developer, you’ll still be a good developer even if JavaScript goes away.

What is actually awesome about JavaScript has nothing to do with JavaScript

No one gets up in the morning and says, I want to have bamboo shoots shoved under my fingernails. (Ok, well maybe some people do, but those guys are still writing object-oriented Perl.)

Yet, at the same time so many developers get up in the morning, fire up their IDE—or excuse me, lightweight text editor which has 50 plugins installed to give the capabilities of an IDE, but is not an IDE—and write JavaScript code. Why do they do it, unless they think JavaScript really is awesome?

It’s because all the stuff around JavaScript and built with JavaScript and on top of JavaScript is actually pretty awesome.

As much as I loathe JavaScript itself, frameworks like JQuery, Durandel, Backbone, Angular, Knockout and more are pretty darn cool.

Not only that, but JavaScript is everywhere!

Every browser is a JavaScript interpreter. Every notebook, PC, tablet, and smartphone can run JavaScript.

There are even cool server technologies, like Node.js that are built with JavaScript.

JavaScript runs in the browser, it has plenty of hooks in it for manipulating the DOM, and it has tons of cool libraries that give you the power to do awesome things, what’s not to love?

This is the part where I tell you what is not to love

What’s not to love, is that all of that stuff has nothing to do with JavaScript itself.

Take JavaScript away and replace it with another programming language and you don’t really miss anything.

Ever seen a movie star without her makeup? Makes you realize that any halfway decent looking woman could be a movie star, with the proper styling.

The same goes for JavaScript. It is a language that has been dressed up to look like something it is not. What we all love about JavaScript is not the language itself, but all that makeup that has been caked on, a little bit of mysterious seduction it infers, and the stylish clothes it wears.

But, what is starting to happen already, and what I believe will continue to happen, is that people will start to get sick of that caked-on makeup look and high maintenance personality of JavaScript.

All those frameworks were really useful at first, but they are becoming such a huge mental burden. Are you worried about what JavaScript framework you need to master and keeping up with what is the hot one to use on any given day? I am.

You can only build so much on top of something else, before you have to wipe the slate clean and start over.

I don’t know when this will happen with JavaScript, but I am pretty sure it will happen.

It is very likely that a language like Dart, that can do everything JavaScript can do and more, will likely someday dethrone our web development king.

JSON sempiternus!

By the way, check out my new experiment on YouTube, going to release a short video each week.  Let me know what you think.

Getting Started With a Programming Project

Follow @jsonmez !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs');

The post Why JavaScript Is Doomed appeared first on Making the Complex Simple.

The key shift with Agile Design is to deliver quickly while handling changes smoothly.   Instead of doing long requirements phases, and heavy documentation up front, with Agile Design you focus on incremental and iterative delivery, going from low-fidelity to high-fidelity, while getting feedback and improving your design.

Here are 10 ways to make Agile Design more effective:

1. Avoid BUFD – Big Up-front Design.  Avoid it.  Whenever there is a big lag time between designing it, developing it, and using it, you’re introducing more risk.  You’re breaking feedback loops.  You’re falling into the pit of analysis paralysis.   Focus on “just enough design” so that you can test what works and what doesn’t, and respond accordingly.
2. Avoid YAGNI – You Aren’t Gonna Need It.  Avoid bloat.  At the same time, avoid scope creep.   “Keep the system uncluttered with extra stuff you guess will be used later. Only 10% of that extra stuff will ever get used, so you are wasting 90% of your time.” – Extreme Programming.org
3. Embrace Occam’s Razor and KISS (Keep It Simple Stupid).  Use the simplest solution.  Simplicity always win in the long run.  This will help you stay in the game before bogging your solution down and crippling it’s ability to keep up with evolving requirements.
4. “Test-First.”   If you don’t know the criteria for what good looks like, you’ll have a hard time finishing.  You’ll also get lost among your designs, unless you clarify what your actual test-cases are.   If you keep a small set of useful tests, you can parse through a variety of designs, and find the diamonds in the rough.
5. Deliver iterative and incremental solutions.   An iterative solution would be decorating the living room.  An incremental solution would be adding a porch to the house.   Deliver useful and usable increments, and then iterate on them to improve them based on real feedback.
6. Cycle through alternatives.   Fail fast and fail often.  This is another good argument for being able to do rapid prototypes, and low-fidelity prototypes.   You need to cycle through competing solutions.   Do A/B testing.  Do the Toyota Way and create 3 alternative solutions.   Don’t get wrapped up in finding the “best solution.”  In many cases, your best solution will be found by “satisficing.”  This will keep you ahead of the game, and ready to respond to emerging requirements.
7. Stay customer-connected.  Stay connected with the users who will actually use what you’re making.   Get 5 customers to stand behind it.  Don’t just throw it over the wall down the line, and hope it sticks.  Invite your customers to your side of the wall.
8. Think Big Picture First.   Put the scaffolding in place.  Focus on the plumbing before the interior decorating.  Solve the big challenges first.   Get the big picture, before getting lost in the details.  Optimize the maxima before the minima.
9. Get cross-discipline feedback early and often.    The better you can balance cross-discipline feedback, the more reliable your solution will be.
10. Spike early and often.  Use technical spikes, functional spikes, and user experience spikes to get the risk out.

The last thing you want to do is throw a solution over the wall, and nobody wants it, or you missed the basic scenarios.   That’s why delivering early helps get the risk out, and helps validate your path.

If you’ve ever watched people argue over how they “satisfied the requirements”, but nobody wants to use it, you know exactly what I mean.  People don’t always know exactly what they want, or, even if they do, it’s hard to articulate in a way, that everybody gets it.  But people are way better at recognizing what they like, and knowing whether or not they like something when they actually use it.

Embrace it.

That’s what Agile Design does – it embraces the reality that people get more clarity over time of what good really looks like.

Creating an early feedback loop also forces you to keep your solution easy to maintain and easy to evolve.  Otherwise, it’s very easy to cement your design, and no longer respond to emerging needs.  The key to lasting solutions is they are built to change.

It’s a process of continuous learning and continuous delivery.

Harish Ganesan CTO of 8KMiles has a very helpful blog, Cloud, Big Data and Mobile, where he shows a nice analytical bent which leads to a lot of practical advice and cost saving tips:

1. Use SQS Batch Requests to reduce the number of requests hitting SQS which saves costs. Sending 10 messages in a single batch request which in the example save $30/month.
2. Use SQS Long Polling to reduce extra polling requests, cutting down empty receives, which in the example saves ~$600 in empty receive leakage costs.
3. Choose the right search technology choice to save costs in AWS by matching your activity pattern to the technology. For a small application with constant load or a heavily utilized search tier or seasonal loads Amazon Cloud Search looks like the cost efficient play. 
4. Use Amazon CloudFront Price Class to minimize costs by selecting the right Price Class for your audience to potentially reduce delivery costs by excluding Amazon CloudFront’s more expensive edge locations.
5. Optimize ElastiCache Cluster costs by right sizing cluster node sizes. For different usage scenarios (heavy, moderate, low) their are optimal instances types. Choosing the right type for the right usage scenario saves money.
6. Amazon Auto Scaling can save costs by better matching demand and capacity. Certainly not a new idea but the diagrams, different leakage scenarios (daily spike, weekly fluctuation, seasonal spike), and the explanation of potential savings (substantial) are well done.
7. Use Amazon S3 Object Expiration feature to delete old backups, logs, documents, digital media, etc. A leakage of ~20 TB adds up to a tidy ~1650 USD a year. 

I have been working on a new version of the Management 3.0 license agreement, with input from the current facilitators and the friends of Happy Melly.

I needed a new agreement because: A) I want to allow other people to create Management 3.0 courseware modules; B) I needed a new pricing model that is more fair; and C) The licensing is taken over by the Happy Melly business network.

Here are 12 reasons why it’s a contract I’m proud of.

1. There is no legalese in this contract. I tested it by asking lots of people to read it, and nobody reported difficulties with the language.
2. There are no extortion prices in this agreement. It does not require USD 10,000 just for the right to use a name, which means it’s interesting for those who are not primarily motivated by big money.
3. The regional pricing based on a purchasing power parity index ensures that licenses are affordable both in wealthy countries and in developing regions.
4. The agreement introduces equality between creators and facilitators. You can produce content, or you can use content, or both. That’s up to you. There is no I-lead-and-you-follow in this system.
5. For facilitators the agreement guarantees freedom of organization, regarding event pricing, registration methods, customizations, evaluations, etc. The only constraint is the message.
6. The agreement guarantees that content creators get paid for the use of their slides, exercises, videos, and games. Free is nice, until you realize you have a mortgage to pay.
7. The agreement guarantees that translators get paid for their help in making content available in other languages and other regions.
8. The agreement has no pyramid scheme in the form of “geographical exclusivity” or “trainer accreditation”. The value is in trust and transparency, not in control and exclusivity.
9. The agreement is event-neutral. It covers everything from 1-hour presentations at conferences to full 2-day in-company courses. It is up to facilitators to decide how bring the message to those who need it.
10. The agreement is brand-neutral. It now mentions the Management 3.0 brand at the top, but this is easily replaced with any other brand. This means you can join us, if you have a great brand to share. {8-)
11. Creators and facilitators sign the contract with Happy Melly, making them a stakeholder of a new business that is cooler than Semco, Virgin, Whole Foods and W.L. Gore combined. {8-)
12. The agreement looks nice. I mean, seriously, why do contracts always look either boring or intimidating?

If you’re interested in creating content for Management 3.0 or facilitating Management 3.0 workshops or courses, go to the Management 3.0 website and fill out the form.

If you have your own brand and content and you’re looking for a way to adopt a similar licensing approach that is fair, simple, transparent, and scalable, contact me or the Happy Melly team.

 

Stand up meetings are the easiest Agile practice to adopt and the easiest to get wrong.  Stand up meeting are teams gatherings held every day to sync the team, to make plans for the day and get roadblocks on the table.  The meeting is designed to be short (15 minutes or less) and participation is limited to the team members only. The discussion among the team members is specifically about issues affecting their work not about collecting status information for outside consumption. The stand up loses effectiveness when it stops being the team’s meeting and becomes the scrum masters meeting.

When the stand-up becomes the scrum master’s meeting to gather status and guide the work we have moved away from self-organization and muddied the lines of communication. When team members begin talking to the scrum masters instead of each other, everyone who is not part of the immediate conversation becomes audience members.  An audience will hang in rapt attention, if the dialog they are listening relates to their needs. However, they will check out when the conversation does not apply to them.  I use the number of phones that suddenly appear (to do email) as a measure of conversational relevance. A good scrum master will ensure that the stand up meeting conversation is between the members rather making the stand up about herself.

Methods & Tools is proud to be the media sponsor of the upcoming Scrum Gathering India Regional 2013 that will take place in Pune, July 36 and 27 2013. For Scrum , Agile and Lean Practitioners, Scrum Gathering India Regional 2013 is a unique opportunity to share and learn from Agile and Scrum community leaders, fellow practitioners and coaches. As a participant, you also get a chance to discuss and deliberate with experts on how to take your organization to next level of maturity using Agile, Scrum, Lean and other new ...

More discussion on LinkedIn about risk, risk management, types of risk, and definitions of risk and opportunity. The "risk management" community in the domains I work is based on Department of Defense, Department of Energy, Department of Homeland Security, NASA, ITIL, AACEI (Association for the Advancement of Cost Engineering International), Nuclear Regulatory Commission, INCOSE (International Council of Systems Engineering), OGC Management of Risk, GAO, and Deloitte's Risk Management Framework.

Several core concepts get confused. So before taking any deep dive into "managing risk," these need to be established.

What is Risk

There are many definitions of risk from a variety of sources. In the end these definitions are all pretty much the same. 

• Risk involves the probability of something happening in the future.
• When that something happens it impacts the project in ways that are not good.
• There can be a probability of the effect of the impact as well.
• Handling the risk means knowing what kind of risk it is, and what the choices are for handling the risk.

Here's a good definition that can be used in probably any domain.

Risk refers to the uncertainty that surrounds future events and outcomes. It is the expression of the likelihood (probability of occurrence) and (probability of) impact of an event with the potential to influence the achievement of an organization’s objectives. - Managing Risk in Government: An Introduction to Enterprise Risk Management, IBM Center for The Business of Government.

I've edited this a bit to remove the likelihood measure and replace it with the probability just to keep the math straight. You'll see why below when it comes to ordinal values in the risk matrix - a bad idea.

There is a time honored  approach to ranking a risk, by calculating some number. This number is meanigless of course, because it has no scale, it is just a ordinal number. We need cardinal numbers for actual risk management.

Risk = Probability of Occurrence x Impact  

This is a trick question. The risk matrix approach that results from this calculation treats these numbers as likelihood not probabilities. But in fact they are probabilities. As well they are Ordinal numbers (1, 2, 3, 4, 5 usually) and as such represents the relative ranking of the likelihood of occurrence, not the actual probability of occurrence.

This approach starts with a major problem - a show stopper problem. The two values on either side of the multiplication sign are probability distributions, not real numbers. There is no MULTIPLY operator between two probability distributions. The is the CONVOLUTION  operator, but that is not likely to be of much value to ordinary project management staff. One starting point for a better understanding of the problems with the risk multiplier and risk matrix approach is the work of Tony Cox. Optimal Design of Qualitative Risk Matrices to Classify Quantitative Risks. Tony's source paper provides the basis for this discussion, "What's Wrong with Risk Matricies."

To put it in blunt terms.

The combination of Ordinal Scales and Risk Matricies are Fatally Flawed

In this link, it is stated again, so I'll restate it here

It is a category mistake to multipy ordinal numbers

By category error it means the objects, the categories, do not have the proper properties to work with the operators. For some more discussion of this topic and a bit of counter discussion, see What's Right with Risk Matricies.

Where does risk come from?

Risk comes from uncertainty. There are two kinds of uncertainty.

• Uncertainty that can be reduced - reducible uncertainty. This is called epistemic uncertainty. This uncertainty is characterized by the lack of knowledge. We can buy this knowledge.
• Uncertainty that cannot be reduced - irreducaable uncertainty. This is called aleatory uncertainty. This uncertainty is an inherent variability in the project processes and characterized by a probability distribution. We can not buy more information about this uncertainty.

The critical point here is the reducibility and the irreducibility of these uncertainties. 

• If the uncertainty is irreducible, then only margin can be used to protect the project from the risk. This is scehdule margin, cost margin, techncial performance margin.
• If the uncertainty is reducible, then we can buy down the uncertainty and therefore buy down the risk. That is we can spend more to find out more information - increase our knowledge. This is done in one of two ways:
  • Spend money in the project to increase our knowledge.
  • Provide a Management Reserve or Contingency to handle the risk when it comes true.

How is Risk Maanged?

We must start with a risk management process. There are several, but they are essentially the same. Here's my favorite, there are others of course, but this one covers all the steps.

So What's the Point Here?

• There is no need to make up definitions for risk and risk management. There are plenty around and all of them are in use on actual projects by actual project and program managers, managing risks every day. Providing your own definitions, is sporty at best. At worst, it shows you haven't done your homework.
• Uncertainty is the source of risk. There are two types of uncertainty - reducible, epistemic and irreducible, aleatory. If you do not separate these two, you cannot credibly have a risk handling plan. If you do not have a credible handling plan, then you're not actually managing risk. 
• Ordinal numbers cannot be used to make risk decisions. Cardinal numbers are needed. No ranking likelihood of occurrence as 1,2,3,4,5. Not allowed, it's bogus. Same for impact. Bogus. And certainly no multiplying those two, even more bogus.
• Risk Management is How Adults Manage Projects - Tim Lister

Related articles Four components of risk Both Aleatory and Epistemic Uncertainty Create Risk Time to Revisit The Risk Discussion When We Say Risk What Do We Really Mean? Uncertainty is the Source of Risk The Barriers to Effective Risk Management

This June I will be running the Property-Based TDD workshop at the XP 2013 conference in Vienna and, with Keith Braithwaite, at SPA2013 in London. This is a hands-on programming workshop to explore how property-based testing influences the TDD process and the designs it produces. The TDD/BDD community has not embraced property-based testing, despite tools having been available for some time for most programming languages. TDD practitioners “triangulate” a property of the system by testing it against multiple examples, selected manually. This is not ideal. Triangulation does not explicitly define the property being tested, giving little scope for automating the selection of test data. People reading a test must infer the property from the data and name of the test, which can be difficult. It is easy to write tests with poor condition/decision coverage. The property-based testing literature has focused on testing for quality assurance. It does not describe property-based testing tools being used to drive development, focus attention, measure progress, and obtain design feedback. (Saff & Boshernitsan’s article on JUnit Theories is a notable exception). In this workshop we will investigate the intersection of TDD and Property-Based Testing. How do we go from examples to properties? Must we start with examples and generalize to properties, or can we start with properties in some cases? How do we change properties as the system grows? Do we start with general properties and specialize them, or specialized properties and generalize? How does that compare to adding examples? Can property-based testing drive design? If we focus on properties, do we get different designs than if we focus on examples? Are some design styles easier than others to describe in terms of properties? Does property­-based testing work better when working top­down/outside-in or bottom­up/inside-out? The workshop is suitable for developers with experience of Test-Driven Development. You can use any language, as long as you can find a property-based testing library for it and somebody to pair with. It would be great if you have already tried Keith Braithwaite's TDD As If You Meant It exercise so we can compare and contrast doing the same exercise with different kinds of testing. Note that this is a workshop, not a tutorial. I don't know the answers. I'm hoping we can find some out together.

Welcome to the Software Process and Measurement Cast 236!

SPaMCAST 236 feature my interview with  Peter Taylor, Ron Rosenhead and Vicki James's we discussed their new book, Strategies for Project Sponsorship.  Sponsors are not necessarily born to the role and unless we want to take pot luck we better understand what makes a good sponsor. 

Vicki James, PMP, CBAP (Seattle, WA, USA)
http://www.project-pro.us  
Vicki is passionate about learning and sharing best practices in project management and business analysis. Certified in both project management (Project Management Professional certification from the Project Management Institute since 2005) and business analysis (Certified Business Analysis Professional from the International Institute of  Business Analysis in since 2010) provides a broad view to support project governance and processes. Vicki spent 11-years in the public sector successfully delivering projects to support governmental operations. Today she provides private consulting to government and private industry clients in addition to writing and presenting on all things project. Vicki is a contributor to The Complete Project Manager (2012) by Randall Englund and Alfonso Bucero as well as a popular blogger and Tweeter.

Peter Taylor, PMP (Coventry UK)
http://www.thelazyprojectmanager.com/
Peter is a dynamic and commercially astute professional who has achieved notable success in Project Management. His background is in project management across three major business areas over the last 26 years, MRP/ERP systems with various software houses and culminating in his current role with Infor, Business Intelligence (BI) with Cognos, and product lifecycle management (PLM) with Siemens. He has spent the last 7 years leading PMOs and developing project managers and is now focusing on project based services development with Infor. He is a professional speaker as well as the author of ‘The Lazy Project Manager’ (Infinite Ideas) and ‘Leading Successful PMOs’ (Gower) and ‘The Lazy Winner’ (Infinite Ideas).

Previous Appearances: 
Lazy Project Manager - SPaMCAST 158
Project From Hell - SPaMCAST 194 

Ron Rosenhead (London, UK)

http://www.ronrosenhead.co.uk/
Ron Rosenhead is known for his highly practical approach to life alongside project management. Over 25 years as a trainer and consultant with the last 17 years specializing in helping organisations to increase the probability of project success. He has personally trained,coached over 10,000 people in the project management world; some project managers, others project sponsors. He has worked across sectors: financial services,public sector, engineering, pharmaceuticals, universities, car retailing, It etc. He is a professional speaker and author of Deliver that Project (an e-book), is a regular blogger and tweeter. Ron regularly writes practical project management training materials which are in use all over the world.

Appreared on SPaMCAST 152 talking about project management 

Order the book at http://strategies4sponsors.com/

The Daily Process Thoughts is my project designed to deliver a quick daily idea, thought or simple smile to help you become a better change agent. Each day you will get piece of thought provoking text and a picture or hand drawn chart to illustrate the idea being presented. The goal is to deliver every day; rain or shine, in sickness or in health or for better or worse! Check it out at www.tcagley.wordpress.com. 

Shameless Ad for my book! 

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team."

NOW AVAILABLE IN CHINESE! 

Have you bought your copy?

Contact information for the Software Process and Measurement Cast

Email:  spamcastinfo@gmail.com
Voicemail:  +1-206-888-6111
Website: www.spamcast.net
Twitter: www.twitter.com/tcagley
Facebook:  http://bit.ly/16fBWV

One more thing!  Help support the SPaMCAST by reviewing and rating the Software Process and Measurement Cast on ITunes!  It helps people find the cast. 

THe Software Process and Measurement Cast is a proud member of the Tech Podcast Network.  Listen to the SPaMCAST and othe great podcasts, like Day In Tech History a podcast on tech hitory 365 days a year at http://www.techpodcasts.com/

Next:
The next Software Process and Measurement Cast will feature an essay on the role of product owners! 

One of my mentees was looking for ways to grow her prowess in “Inspiring a Vision.”  

Here are some of the ways I shared with her so far:

• Future Picture - One of the best ways that the military uses to create a shared vision rapidly and communicate it down the line is “Future Picture”  (See How To Paint a Future Picture.)

The key with vision is, when possible –

1. Draw your vision – make it a simple picture
2. Use metaphors – metaphors are the fastest way to share an idea
3. Paint the story - what’s the current state, what’s the future state
4. Paint the ecosystem – who are the players in the system, what are the levers, what are the inputs/outputs
5. Paint the story over time … how does time change the vision … and chunk up the vision into 6 month, 1 year, 3 year, five year

And, a powerful tool we use at Microsoft is a Vision / Scope document.

Sometimes the best way to do something well, is to know what to avoid.  In Ex-Windows Boss Steve Sinofsky: Here's Why I Use An iPhone, Nicholas Carlson shares some tips from Steve Sinofsky on analyzing the competition:

1. Don't use the product in a lightweight manner
2. Don't think like yourself
3. Don't bet competitors act similarly (or even rationally)
4. Don't assume the world is static

Sinofsky elaborates, and says to use the product deep, and use it over time.  Use the product like it was intended by the designers.  Wrap yourself around the culture, constraints, resources, and more of a competitor.  And, don't take a static view of the world -- the competitor can always update their product based on feedback, or weaknesses you call out.

Recently my wife and I hiked the Jinshangling portion of the Great Wall of China, which was originally built during early in the Ming Dynasty. It was then later restored into what we now recognize as one of the most iconic portion of the Wall under Ming General Qi Jiquang. While the project to build the great wall was not exactly Agile and probably did not foster participatory management, this section of Wall is said to reflect the vision of Qi Jiquang, its product owner, which was different than other sections of the Great Wall. According to guides in the area, Qi Jiquang was based in the area and used his well-fed troops to build the wall (rather than other forms of staffing/servitude elsewhere). Qi Jiquang lived and interacted with his men on a daily basis in other sections of the Wall absentee product owners prevalent. Absentee product owners can’t provide their vision or motivate the team something that the great general knew.

Looking out at the some of the most iconic views of the Great Wall drives home the point that when IT and business work together to achieve a well-crafted vision, great things can happen.

I’ve been using Sublime a bit recently and one thing I wanted to do was put neo4j cypher queries into files with arbitrary extensions and have them recognised as cypher files every time I open them.

I’m using the cypher Sublime plugin to get the syntax highlighting but since I’ve got my cypher in a .haml file it only remembers that it should have cypher highlighting as long as the file is open.

As soon as I close and then re-open the file it goes back to being highlighted as HAML.

I initially thought that the way around this would be to write a plugin which kept track of files that you’d manually assigned a syntax to but then I came across the ApplySyntax plugin which seems even better.

ApplySyntax allows you to assign syntaxes to files based on regular expression matching on the file name or on the first line of the file.

At the moment, the easiest way to detect that a file is a cypher query is that the first line will begin with ‘START’ so I wrote the following in my user settings file:

~/Library/Application Support/Sublime Text 2/Packages/User/ApplySyntax.sublime-settings

{
	"reraise_exceptions": false,
	"new_file_syntax": false,
	"syntaxes": [
		{			
			"name": "Cypher",
			"rules": [
				{"first_line": "^START"}
			]
		}	
	]
}

ApplySyntax is a pretty neat plugin, worth having a look if you have this problem to solve!

I’m a fan of anticipating the future, and creating the future.  Even speculation helps dream up what’s possible, and be ready for anything, when it happens.  And if you balance that with key trends, you can really stay on top of things.

After all, what’s The Art of the Long View teach us?  While we can’t predict the future, we can better prepare for it by playing out the “what if” scenarios and possibilities.

With that in mind, I did a search on Microsoft secret stuff, and found some interesting things.  After all, Microsoft spends more on R&D than Google and Apple combined.

Here are some of the more interesting articles I found:

• Meet Microsoft, the world’s best kept R&D secret
• XBox Surface: Microsoft's 7-inch gaming tablet
• Microsoft's 'Secret' Projects That Will Completely Rock Your World
• Windows XP Retiring In Time For Microsoft Glasses
• Xbox leak reveals Kinect2, augmented reality glasses

Here are my key take aways …

• Holodeck - transform your family space into a something like Star Trek’s famous holodeck.
• Kinect Glasses (Fortaleza) - wearable peripherals and augmented reality.
• Xbox Surface – a 7-inch Xbox tablet.

Kinect Stuff

• Kinect Fusion - create interactive 3D models.
• KinectTrack - a new six degree-of-freedom (6-DoF) tracker which allows real-time and low-cost pose estimation using only commodity hardware.
• SuperKid - Use Kinect to make movies: watch yourself against a virtual background, and interact with virtual props.

Touch and Touch Screens

• LightSpace - create interactive displays on everyday objects.
• OmniTouch - displays graphical images onto virtually any surface and transform the projection into an interactive, multi-touch-enabled input.
• Sidesight - expand a mobile device's multi-touch capabilities beyond the size of its screen.
• SkinPut - beam interactive displays onto your hand and arm
• Thinsight - a hardware and software product that allows ordinary LCD screens to become fully functional multi-point touchscreens.

More …

• Digits - translate a user’s hand movements directly into a virtual space.
• Foveated Rendering - accelerate graphics computation by a factor of 5-6 on a desktop HD display, by exploiting the fallout of acuity in the visual periphery.

What neat stuff do you see Microsoft working on?

by The GTAC Committee

The Google Test Automation Conference (GTAC) was held last week in NYC on April 23rd & 24th. The theme for this year's conference was focused on Mobile and Media. We were fortunate to have a cross section of attendees and presenters from industry and academia. This year’s talks focused on trends we are seeing in industry combined with compelling talks on tools and infrastructure that can have a direct impact on our products. We believe we achieved a conference that was focused for engineers by engineers. GTAC 2013 demonstrated that there is a strong trend toward the emergence of test engineering as a computer science discipline across companies and academia alike.

All of the slides, video recordings, and photos are now available on the GTAC site. Thank you to all the speakers and attendees who made this event spectacular. We are already looking forward to the next GTAC. If you have suggestions for next year’s location or theme, please comment on this post. To receive GTAC updates, subscribe to the Google Testing Blog.

Here are some responses to GTAC 2013:

“My first GTAC, and one of the best conferences of any kind I've ever been to. The talks were consistently great and the chance to interact with so many experts from all over the map was priceless.” - Gareth Bowles, Netflix

“Adding my own thanks as a speaker (and consumer of the material, I learned a lot from the other speakers) -- this was amazingly well run, and had facilities that I've seen many larger conferences not provide. I got everything I wanted from attending and more!” - James Waldrop, Twitter

“This was a wonderful conference. I learned so much in two days and met some great people. Can't wait to get back to Denver and use all this newly acquired knowledge!” - Crystal Preston-Watson, Ping Identity

“GTAC is hands down the smoothest conference/event I've attended. Well done to Google and all involved.” - Alister Scott, ThoughtWorks

“Thanks and compliments for an amazingly brain activity spurring event. I returned very inspired. First day back at work and the first thing I am doing is looking into improving our build automation and speed (1 min is too long. We are not building that much, groovy is dynamic).” - Irina Muchnik, Zynx Health

by The GTAC Committee

GTAC is just around the corner, and we’re all very busy and excited. I know we say this every year, but this is going to be the best GTAC ever! We have updated the GTAC site with important details:

• The Schedule 
• Speaker Profiles 
• Committee Profiles 

If you are on the attendance list, we’ll see you on April 23rd. If not, check out the Live Stream page where you can watch the conference live and can get involved in Q&A after each talk. Perhaps your team can gather in a conference room and attend remotely.

By The GTAC Committee

The next and seventh GTAC (Google Test Automation Conference) will be held on April 23-24, 2013 at the beautiful Google New York office! We had a late start preparing for GTAC, but things are now falling into place. This will be the second time it is hosted at our second largest engineering office. We are also sticking with our tradition of changing the region each year, as the last GTAC was held in California.

The GTAC event brings together engineers from many organizations to discuss test automation. It is a great opportunity to present, learn, and challenge modern testing technologies and strategies. We will soon be recruiting speakers to discuss their innovations.

This year’s theme will be “Testing Media and Mobile“. In the past few years, substantial changes have taken place in both the media and mobile areas. Television is no longer the king of media. Over 27 billion videos are streamed in the U.S. per month. Over 1 billion people now own smartphones. HTML5 includes support for audio, video, and scalable vector graphics, which will liberate many web developers from their dependence on third-party media software. These are incredibly complex technologies to test. We are thrilled to be hosting this event in which many in the industry will share their innovations.

Registration information for speakers and attendees will soon be posted here and on the GTAC site (https://developers.google.com/gtac). Even though we will be focusing on “Testing Media and Mobile”, we will be accepting proposals for talks on other topics.

By The GTAC Committee

We are happy to announce that the application process is now open for presentation proposals and attendance for the seventh GTAC (Google Test Automation Conference) to be held at the Google New York office on April 23 - 24th, 2013.

GTAC brings together engineers from many organizations to discuss test automation. It is a great opportunity to present, learn, and challenge modern testing technologies and strategies. GTAC will be streamed live on YouTube this year, so even if you can’t attend, you’ll be able to watch the conference from your computer.

Speakers
Presentations are targeted at student, academic, and experienced engineers working on test automation. Full presentations and lightning talks are 45 minutes and 15 minutes respectively. Speakers should be prepared for a question and answer session following their presentation. As mentioned in our recent post, the main theme is on testing media and mobile, however, we will consider proposals on other topics.

Application
For presentation proposals and/or attendance, complete this form. We will be selecting about 200 applicants for the event.

Deadline
The due date for both presentation and attendance applications is Jan 23rd, 2013.

Fees
There are no registration fees. We will send out detailed registration instructions to each invited applicant. We will provide meals. Attendees must arrange their own travel and accommodations.