Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator

Making Decisions

Herding Cats - Glen Alleman - Sat, 09/06/2014 - 23:07

Making Multi-Objective DecisionsAlmost all decision problems involve the simultaneous considerations of different objectives that are many times in conflict.

In the software development world this might be characterized by a customer wanting a set of features to be delivered for a budget on a certain date so those features can be put to work earning back their cost.

Since the list of features is likely to needed to be developed in a specific order with varying costs, the question is what features should be done first and what features down next

The traditional response from an agile developer is the define the value of those features and produce them in that order. What is the unit of measure of value. That's rarely stated. But along with the Value is the cost of that value and other attributes of the development process. Risk, resource demand, inter dependencies between other features, inter dependencies between these features and external processes - the externalities of all complex problems.

The formal discipline is this process is called Multi-Criteria Decision Analysis (MCDA). MCDA has the following elements:

  • A goal, objective, or criteria to be achieved
  • A  need to be fulfilled
  • Constraints and requirements associated with and affected by the decision
  • Decision options or alternatives
  • The Environment in which the decision must be made
  • The Experience and background of the decision makers

The methods to solve these types of problems started in the 1950's with Churchman and Ackoff, and were axiomatized by Debreu in 1960, along with Luce and Tukey, Krantz, and Scott.

The principles in these early papers and the continued development of multi-criteria decision making have now moved to nearly every domain where scarce resources, probabilistic outcomes, uncertainty of the impact of the decisions, and value at risk is high enough to ask the question

What will be the outcome of this decision on the future of the processes, cost, technology, environment, or any other external domain?

So when we hear that

  • Decision making frameworks for project that don't require estimates.
  • Investment models for software project that don't require estimates.
  • Project management (risk management, scope management, process reports) approaches that don't require estimates.

We have to wonder if these frameworks, investment models, and project management methods have come in contact with the reality of how business works. As Carl saying in a somewhat harsh manner

Extraordinary claims require extraordinary evidence. Carl Sagan

Related articles Positive Deviance 5 Questions That Need Answers for Project Success
Categories: Project Management

10 High-Value Activities in the Enterprise

I was flipping back over the past year and reflecting on the high-value activities that I’ve seen across various Enterprise customers.  I think the high-value activities tend to be some variation of the following:

  1. Customer interaction (virtual, remote, connect with experts)
  2. Product innovation and ideation.
  3. Work from anywhere on any device.
  4. Comprehensive and cross-boundary collaboration (employees, customers, and partners.)
  5. Connecting with experts.
  6. Operational intelligence (predictive analytics, predictive maintenance)
  7. Cross-sell / up-sell and real-time marketing.
  8. Development and ALM in the Cloud.
  9. Protecting information and assets.
  10. Onboarding and enablement.

At first I was thinking of Porter’s Value Chain (Inbound Logistics, Operations, Outbound Logistics, Marketing & Sales, Services), which do help identify where the action is.   Next, I was reviewing how when we drive big changes with a customer, it tends to be around changing the customer experience, or changing the employee experiences, or changing the back-office and systems experiences.

You can probably recognize how the mega-trends (Cloud, Mobile, Social, and Big Data) influence the activities above, as well as some popular trends like Consumerization of IT.

High-Value Activities in the Enterprise from the Microsoft “Transforming Our Company” Memo

I also found it helpful to review the original memo from July 11, 2013 titled Transforming Our Company.  Below are some of my favorite sections from the memo:

Via Transforming Our Company:

We will engage enterprise on all sides — investing in more high-value activities for enterprise users to do their jobs; empowering people to be productive independent of their enterprise; and building new and innovative solutions for IT professionals and developers. We will also invest in ways to provide value to businesses for their interactions with their customers, building on our strong Dynamics foundation.

Specifically, we will aim to do the following:

  • Facilitate adoption of our devices and end-user services in enterprise settings. This means embracing consumerization of IT with the vigor we pursued in the initial adoption of PCs by end users and business in the ’90s. Our family of devices must allow people to be more productive, and for them to easily use our devices for work.

  • Extend our family of devices and services for enterprise high-value activities. We have unique expertise and capacity in this space.

  • Information assurance. Going forward this will be an area of critical importance to enterprises. We are their trusted partners in this space, and we must continue to innovate for them against a changing security and compliance landscape.

  • IT management. With more IT delivered as services from the cloud, the function of IT itself will be reimagined. We are best positioned to build the tools and training for that new breed of IT professional.

  • Big data insight. Businesses have new and expanded needs and opportunities to generate, store and use their own data and the data of the Web to better serve customers, make better decisions and design better products. As our customers’ online interactions with their customers accelerate, they generate massive amounts of data, with the cloud now offering the processing power to make sense of it. We are well-positioned to reimagine data platforms for the cloud, and help unlock insight from the data.

  • Customer interaction. Organizations today value most those activities that help them fully understand their customers’ needs and help them interact and communicate with them in more responsive and personalized ways. We are well-positioned to deliver services that will enable our customers to interact as never before — to help them match their prospects to the right products and services, derive the insights so they can successfully engage with them, and even help them find and create brand evangelists.

  • Software development. Finally, developers will continue to write the apps and sites that power the world, and integrate to solve individual problems and challenges. We will support them with the simplest turnkey way to build apps, sites and cloud services, easy integration with our products, and innovation for projects of every size.”

A Story of High-Value Activities in Action

If you can’t imagine what high-value activities look like, or what business transformation would look like, then have a look at this video:

Nedbank:  Video Banking with Lync

Nedbank was a brick-and-mortar bank that wanted to go digital and, not just catch up to the Cloud world, but leap frog into the future.  According to the video description, “Nedbank initiated a program called the Integrated Channel Strategy, focusing on client centered banking experiences using Microsoft Lync. The client experience is integrated and aligned across all channels and seeks to bring about efficiencies for the bank. Video banking with Microsoft Lync gives Nedbank a competitive advantage.”

The most interesting thing about the video is not just what’s possible, but that’s it’s real and happening.

They set a new bar for the future of digital banking.

You Might Also Like

Continuous Value Delivery the Agile Way

How Can Enterprise Architects Drive Business Value the Agile Way?

How To Use Personas and Scenarios to Drive Adoption and Realize Value

Categories: Architecture, Programming

Software architecture vs code

Coding the Architecture - Simon Brown - Sat, 09/06/2014 - 09:11

My Software architecture vs code talk has evolved considerably over the past year and I've presented a number of iterations at events in Europe and the US. If you're interested, thanks to the nice people behind the GOTO conferences, you can now watch the video of the version that I presented at GOTO Chicago 2014.

During September I'll be presenting a new version of this session at Foo Café in Malmö, Software Architecture Summit in Berlin and DevDay in Krakow. See you there!

Categories: Architecture

Project Sponsor Anti-patterns

Some Anti-Patterns Should Be Avoided

Some Anti-Patterns Should Be Avoided

Wikipedia describes an anti-pattern as a response to a typical problem that is ineffective or potentially counterproductive. There are numerous ways to implement project sponsorship that work (patterns) and just as many that don’t work (anti-patterns). Reviewing the four of the most typical anti-patterns and some ideas on how to mitigate the negative impact is illustrative of the problems teams and organizations face.

  1. Absentee Sponsor: If you have not seen or talked to your sponsor in recent memory you are dealing with the problem of an absentee sponsor. Absentee sponsors can occur for a number of reasons including a project without an identified sponsor, a sponsor that is overburdened or an uninterested sponsor. Each specific cause requires a slightly different course of action; however the underlying cause generally is a problem of portfolio management. In many cases these problems are a reflection of starting more projects than the organization can work on effectively at one time. By starting too many projects the organization will struggle to either find sponsors that are directly interested in the project or can spend the time needed. One organization I worked with required a commitment to engage by a business sponsor before they would consider a project. Sponsors provide influence and resources needed by a project to be effective. Projects that fail this basic hurdle should be postponed. If an active project is suffering from an absentee sponsor, the project lead should, at the very least, escalate the issue as a critical risk as high up in organizational hierarchy as possible.
  2. Underpowered Sponsor: Underpowered sponsors can’t provide enough support, influence or resources for the project to effectively and efficiently deliver value. Underpowered sponsors usually are caused by two situations: The first, like absentee sponsors, is a reflection of a portfolio issue. The second issue is often a reflection of someone new to the ranks of senior management or the ranks of being a sponsor. The simplest solution to the second issue is for the “underpowered sponsor” to find an organizational ally (or allies) to augment their organizational power. A more radical solution would be to replace the underpowered sponsor; however, this should be a last resort solution and only used for critical projects.
  3. Proxy Sponsor: A proxy sponsor is a stand-in for the person that should be the sponsor. Proxy sponsors occur for many of the same reasons as absentee or underpowered sponsors; however, in this case someone has recognized the problem and tried to patch the problem. In many cases the “real” sponsor has delegated the responsibility for sponsorship either to IT or to his/her direct report. Decision-making in projects with proxy sponsors will take longer and will typically suffer from more interruptions from higher priority activities. Projects in this scenario should seek to identify decisions and support needs that are outside of the team’s span of control as early possible and avoid waiting for the escalation and validation process to catch up. One solution I suggest is that the proxy schedule periodic meetings which a more senior sponsor (a decision-maker) to ensure the wait time for decisions to be made is minimized.
  4. Role Conflict: Sponsors should not be project managers, Scrum masters or product owners. Occasionally, sponsors are seduced to the dark side and attempt to play one or more of these roles. Usually when a sponsor tries to play any of these roles on top of being the project sponsor (and in addition to their day job) they will be overwhelmed. In most cases the project leader should discuss the problem with the sponsor and ensure they have the proper training need to effectively act as a sponsor.

Effective project sponsorship is critical for any project to deliver the value described in project’s business case. The anti-patterns are most often a reflection of the poor portfolio management. Starting too many projects at once slows all projects down and typically means less gets done than if a more measured approach were taken. A project should not be started unless the right sponsor (which includes making sure they are trained to be a sponsor) is identified and they agree to take on the role. The right sponsor will be able to provide the right level of interest, influence and resources. Any other solution might help but will not solve the problem in the long run!

Categories: Process Management

Episode 209: Josiah Carlson on Redis

Josiah Carlson discusses Redis, an in-memory single-threaded data structure server. A Redis mailing list contributor and author, Josiah talks with Robert about the differences between Redis and a key-value store, client-side versus server-side data structures, consistency models, embedding Lua scripts within the server, what you can do with Redis from an application standpoint, native locking […]
Categories: Programming

Stuff The Internet Says On Scalability For September 5th, 2014

Hey, it's HighScalability time:

Telephone Tower, late 1880s, 5000 telephone lines. Switching FTW.
  • 1.3 trillion: row table in SQL server; 100,000: galaxies in the Laniakea supercluster.
  • Quotable Quotes:
    • @pbailis: OLAP: data at rest, queries in motion. Stream processing: data in motion, queries at rest. PSoup: data in motion, queries in motion.
    • @ronpepsi: Scaling rule: addressing one bottleneck always starts the clock ticking on another one. (The same goes for weak links in chains.)
    • @utahkay: Our mental models are deterministic, and break down when you reach high utilization in a stochastic system. 

  • Instagram introduced Hyperlapse, their answer to a world that doesn't move fast enough already. And here's the story of how they did it: The Technology behind Hyperlapse from Instagram. It combines time travel and psychadelics, I think you'll enjoy it.

  • Etsy CEO to Businesses: If Net Neutrality Perishes, We Will Too. The idea of being a common carrier is old, deep, and powerful. It creates markets that grow rather than monopolies the choke economies to death. Ferries were required to be common carriers, that is they must ferry all people and goods at the same price.  Otherwise communities would not survive. AT&T became a monopoly on the promise of universal service and becoming a common carrier for all. The Internet is a more important version of the same idea.

  • To make lots and lots of money you need to hitch your star to a fast growing something. Google placed ads on an exponentially expanding inventory of 3rd party web content. Winner. Now Google is exploiting another phenomena experiencing an exponential growth curve: data. This time they aren't placing ads, they are calculating functions with BigQuery. Put On Your Streaming Shoes is a story showing just why and how this jump to another fast growing something will likely succeed.

  • Just an incredible look into the structure behind PhotoGate. Notes on the Celebrity Data Theft. These aren't just script kiddies. These are sophisticated and organized groups. Are hacker networks the new roving band of Vikings looking to rape and pillage? Though it would help if the villages were better protected.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge (which means this post has many more items to read so please keep on reading)...

Categories: Architecture

Focus on Value is Only ½ The Equation

Herding Cats - Glen Alleman - Fri, 09/05/2014 - 16:54

ValueWhenever I hear "we need to focus on value" it tells me that only ½ the equation of business  success is understood.

Absolutely value is needed and is the focus of our work efforts. No customer is going to pay for a product or service that doesn't have the needed value. This value is usually in a unit of measure around a "capability" to do something for the that in turn solves a problem, generates revenue, enables another process to function.

Measures of Effectiveness to get the job done. Measures of Performance while getting the job done. The Technical Performance Measures of the underlying hardware, software, people processes that enable the job to get done at the right cost.

But this value is an enabler. The units of measure of the value are defined by the customer, not the provider. The Marketing department of the provider may have suggestions about the value of the product or service, but it is the customer that confirms that value.

In doing the confirmation of Value, the buyer (internal or extermal customer) makes this assessment using a foundational principles of all business decisions...


Microeconomics is a branch of economics that studies the behavior of individuals and small impacted organizations in making decisions on the allocation of limited resources. Those limited resources to the buyer are:

  • Time - the need for the capability provided by the Value produced by the developer usually has a time frame on it. If that Value could arrive any time, then it is unlikely the Value of the Value is very high.
  • Money - the other limited resource is money. How much does the Value cost?

The time value of money is then used by the buyer to enable another decision making process

ROI = (Value - Cost ) / Cost

So when we hear, we don't need to know the cost, that is we don't need to estimate the cots of producing the value, think again. This can only be true if the delivered value takes place in the presence of unlimited resources. That is we have all the time we need and no one really cares about the cost. That is the principle of microeconomics of business decision making is not in play.

As a final point. Budget is NOT Cost. Setting the budget, only sets the budget. The cost of the work is called Actual Cost and actual cost is generated by exchanging labor and materials for money. So setting the budget is needed. But setting the budget only says what the expected cost might be. If you're given an budget and an expected set of Value outcomes, estimates of the confidence of delivering that Value will be needed. Otherwise your budget is just a number, that will easily be blown before you delivery the needed capabilities on the needed date.

If asked what should our budget be for the expected Value, then solving the ROI or Expected Monetary Value, or Value at Risk needs to take place. In order to do this for a decision about the future ROI, EMV, or VAR, we need to estimate both the Cost and Value - then manage the project that produces the Capabilities that deliver the Value toward both those cost and time variables. And of course those variables are random variables.

When it is stated in an work shop where the participants will learn about

  • Decision making frameworks for project that don't require estimates.
  • Investment models for software project that don't require estimates.
  • Project management (risk management, scope management, process reports) approaches that don't require estimates.

Then those processes are not operating in a governance domain where microeconomics of product developments are in place. Can't say where they are operating, but it's not on this planet of a for profit business. Or those proffering this approach have discovered a secret sauce that gets around the basic principles of all business -

Profit = Revenue - Cost of Goods Sold

The only place I know this principle is not in place, is here in Colorado, just outside of Fairplay, CO, is South Park.


Here in South Park, the local businessmen have a clever plan to get rich without be subject to microeconomics of making decisions about how to do that.

Screen Shot 2014-09-05 at 9.39.44 AM

Categories: Project Management

Standard Markdown is now Common Markdown

Coding Horror - Jeff Atwood - Fri, 09/05/2014 - 01:23

Let me open with an apology to John Gruber for my previous blog post.

We've been working on the Standard Markdown project for about two years now. We invited John Gruber, the original creator of Markdown, to join the project via email in November 2012, but never heard back. As we got closer to being ready for public feedback, we emailed John on August 19th with a link to the Standard Markdown spec, asking him for his feedback. Since John MacFarlane was the primary author of most of the work, we suggested that he be the one to reach out.

We then waited two weeks for a response.

There was no response, so we assumed that John Gruber was either OK with the project (and its name), or didn't care. So we proceeded.

There was lots of internal discussion about what to name our project. Strict Markdown? XMarkdown? Markdown Pro? Markdown Super Hyper Turbo Pro Alpha Diamond Edition?

As we were finalizing the name, we noticed on this podcast, at 1:15 …

… that John seemed OK with the name "GitHub Flavored Markdown". So I originally wrote the blog post and the homepage using that terminology – "Standard Flavored Markdown" – and even kept that as the title of the blog post to signify our intent. We were building Yet Another Flavor of Markdown, one designed to remove ambiguity by specifying a standard, while preserving as much as possible the spirit of Markdown and compatibility with existing documents.

Before we went live, I asked for feedback internally, and one of the bits of feedback I got was that it was inconsistent to say Standard Flavored Markdown on the homepage and blog when the spec says Standard Markdown throughout. So I changed them to match Standard Markdown, and that's what we launched with.

It was a bit of a surprise to get an email last night, addressed to both me and John MacFarlane, from John Gruber indicating that the name Standard Markdown was "infuriating".

I'm sorry the name is so infuriating. I assure you that we did not choose the name to make you, or anyone else, angry. We were simply trying to pick a name that correctly and accurately reflected our goal – to build an unambiguous flavor of Markdown. If the name we chose made inappropriate overtures about Standard Markdown being anything more than a highly specified flavor of Markdown, I apologize. Standard does have certain particular computer science meanings, as in IETF Standard, ECMA Standard. That was not our intent, it was more of an aspirational element of "what if, together, we could eventually..". What can I say? We're programmers. We name things literally. And naming is hard.

John Gruber was also very upset, and I think rightfully so, that the word Markdown was not capitalized throughout the spec. This was an oversight on our part – and also my fault because I did notice Markdown wasn't capitalized as I copied snippets of the spec to the homepage and blog post, and I definitely thought it was odd, too. You'll note that I took care to manually capitalize Markdown in the parts of the spec I copied to the blog post and home page – but I neglected to mention this to John MacFarlane as I should have. We corrected this immediately when it was brought to our attention.

John then made three requests:

  1. Rename the project.

  2. Shut down the domain, and don't redirect it.

  3. Apologize.

All fair. Happy to do all of those things.

Starting with the name. In his email John graciously indicated that he would "probably" approve a name like "Strict Markdown" or "Pedantic Markdown". Given the very public earlier miscommunication about naming, that consideration is appreciated.

We replied with the following suggestions:

  • Compatible Markdown
  • Regular Markdown
  • Community Markdown
  • Common Markdown
  • Uniform Markdown
  • Vanilla Markdown

We haven't heard back after replying last night, and I'm not sure we ever will, so in the interest of moving ahead and avoiding conflict, we're immediately renaming the project to Common Markdown.

We hope that is an acceptable name; it was independently suggested to us several times in several different feedback areas. The intention is to avoid any unwanted overtones of ownership; we have only ever wanted to be Yet Another Flavor of Markdown.

  1. The project name change is already in progress.

  2. This is our public apology.

  3. I'll shut down the domain as soon as I can, probably by tomorrow.

John, we deeply apologize for the miscommunication. It's our fault, and we want to fix it. But even though we made mistakes, I hope it is clear that everything we've done, we did solely out of a shared love of Markdown (and its simple, unencumbered old-school ASCII origins), and the desire to ensure the success of Markdown as a stable format for future generations.

Edit: after a long and thoughtful email from John Gruber – which is greatly appreciated – he indicated that no form of the word "Markdown" is acceptable to him in this case. We are now using the name CommonMark.

[advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you.
Categories: Programming

Sponsors: The Resources, Influence and Interest Equation

Not everyone has what it takes to be a sponsor.

Not everyone has what it takes to be a sponsor.

Not everyone can or should be a sponsor. Good sponsorship requires resources, influence and interest in varying degrees.


Influence is the ability to make something happen or in some cases to make “things” not happen. Sponsors apply influence in a variety of ways including helping teams acquire resources or to remove barriers. Early in my career I had to ask a sponsor to make a call to get a schedule change so that my team did not have to move offices the week before a major production implementation. Influence can be used to remove barriers that are outside of the team’s control.

Resources, in their simplest form, begin with the check (budget) that the sponsor writes for the project. Managers transform the budget into a team, buy software, and secure team workspace or other project needs. Without resources, the duration of any project will be very short.

Interest is the feeling of wanting to learn more about the project which translates into attention, concern, or curiosity. The higher the level of interest in a project the more energy the sponsor will expend to pay attention to what is happening as the project progresses.

Project criticality, defined as the quality, state or degree of being of the highest importance, will impact the type of sponsor required. How does project criticality affect the need for specific levels of resources, influence and interest equation?


Resources (at least over short to medium term) are closer to constant than a variable, either the project has the resources required or they do not. While there are theoretical discussions on the impact of somewhat constraining a project by providing them slightly less than what is requested, if a project does not have enough money they fail sooner or later. The higher the level of criticality more important the sponsor’s access to resources will be to ensure the project is not negatively constrained.

Criticality and the need for a sponsor to provide influence are positively correlated. The more critical a project, the more influence a sponsor may need to bring to bear to ensure focus and fend off distractions. Consider the impact to a project to a project if a team needs to be diverted to deal with urgent, but not important, interruptions. Interruptions rarely positively impact a project, and the higher the criticality the higher the chance that an avoidable interruption will impact the team or the project’s value.

While sponsors should be interested in any project they sponsor; the more critical a project is the more interest they will need to exhibit. Critical projects generally need the attention and involvement high levels of interest generate.   A sponsor that pays attention to project will be better positioned to provide support, motivation, influence and extra resources if needed.

Sponsors that cannot deliver the proper level resources, influence or interest for their projects will be poor sponsors. Projects of all types need to understand that because sponsors are human there will be variability in the amount of resources, influence and interest that can be brought to bear and attributes like criticality will required different levels of support. Project leaders and teams approach potential gaps in sponsorship as a risk, and should be assessed and mitigated if needed.

Categories: Process Management

Welcome to the Swift Playground

Xebia Blog - Thu, 09/04/2014 - 19:16

Imagine... You're working in swift code and you need to explain something to a co-worker. Easiest would be to just explain it and show the code right. So you grab your trusty editor and type some markdown.

let it = "be awesome"


So now you have a file filled with content:

But it would be better if it looked like:


Well you can and it's super simple, all you need is some Markdown and:

npm install -g swift-playground-builder

After that it's a matter of running:



More info:

Email Effectiveness–Write Good Subject Lines

Software Requirements Blog - - Thu, 09/04/2014 - 17:00
Email is a significant part of my business life, and probably yours as well. I really appreciate a well-written email. And, I’m frequently frustrated by a poorly written one. Janelle Estes’ recent post, Email Subject Lines: 5 Tips to Attract Readers is written with newsletters in mind, but I think most of the points generalize […]
Categories: Requirements

10 Big Ideas from The 7 Habits of Highly Effective People

It’s long over-do, but I finally wrote up my 10 Big Ideas from the 7 Habits of Highly Effective People.

What can I say … the book is a classic.

I remember when my Dad first recommended that I read The 7 Habits of Highly Effective People long ago.   In his experience, while Tony Robbins was more focused on Personality Ethic, Stephen Covey at the time was more focused on Character Ethic.  At the end of the day, they are both complimentary, and one without the other is a failed strategy.

While writing 10 Big Ideas from the 7 Habits of Highly Effective People, I was a little torn on what to keep in and what to leave out.   The book is jam packed with insights, powerful patterns, and proven practices for personal change.   I remembered reading about the Law of the Harvest, where you reap what you sow.  I remembered reading about how to think Win/Win, and how that helps you change the game from a scarcity mentality to a mindset of abundance.   I remembered reading about how we can move up the stack in terms of time management if we focus less on To Dos and more on relationships and results.   I remembered reading about how if we want to be heard, we need to first seek to understand.

The 7 Habits of Highly Effective People is probably one of the most profound books on the planet when it comes to personal change and empowerment.

It’s full of mental models and big ideas.  

What I really like about Covey’s approach is that he bridged work and life.  Rather than splinter our lives, Covey found a way to integrate our lives more holistically, to combine our personal and professional lives through principles that empower us, and help us lead a more balanced life.

Here is a summary list of 10 Big Ideas from the 7 Habits of Highly Effective People:

  1. The Seven Habits Habits of Effectiveness.
  2. The Four Quadrants of Time Management.
  3. Character Ethic vs. Personality Ethic
  4. Increase the Gap Between Stimulus and Response.
  5. All Things are Created Twice.
  6. The Five Dimensions of Win/Win.
  7. Expand Your Circle of Influence.
  8. Principle-Centered Living.
  9. Four Generations of Time Management.
  10. Make Meaningful Deposits in the Emotional Bank Account.

In my post, I’ve summarized each one and provided one of my favorite highlights from the book that brings each idea to life.


Categories: Architecture, Programming

Optimizing for Bandwidth on Apache and Nginx

Google Code Blog - Thu, 09/04/2014 - 16:27
This post originally appeared on Webmaster Central
by Jeff Kaufman, Make the Web Fast

Webmaster level: advancedEveryone wants to use less bandwidth: hosts want lower bills, mobile users want to stay under their limits, and no one wants to wait for unnecessary bytes. The web is full of opportunities to save bandwidth: pages served without gzip, stylesheets and JavaScript served unminified, and unoptimized images, just to name a few.So why isn't the web already optimized for bandwidth? If these savings are good for everyone then why haven't they been fixed yet? Mostly it's just been too much hassle. Web designers are encouraged to "save for web" when exporting their artwork, but they don't always remember.  JavaScript programmers don't like working with minified code because it makes debugging harder. You can set up a custom pipeline that makes sure each of these optimizations is applied to your site every time as part of your development or deployment process, but that's a lot of work.

An easy solution for web users is to use an optimizing proxy, like Chrome's. When users opt into this service their HTTP traffic goes via Google's proxy, which optimizes their page loads and cuts bandwidth usage by 50%.  While this is great for these users, it's limited to people using Chrome who turn the feature on and it can't optimize HTTPS traffic.

With Optimize for Bandwidth, the PageSpeed team is bringing this same technology to webmasters so that everyone can benefit: users of other browsers, secure sites, desktop users, and site owners who want to bring down their outbound traffic bills. Just install the PageSpeed module on your Apache or Nginx server [1], turn on Optimize for Bandwidth in your configuration, and PageSpeed will do the rest.

If you later decide you're interested in PageSpeed's more advanced optimizations, from cache extension and inlining to the more aggressive image lazyloading and defer JavaScript, it's just a matter of enabling them in your PageSpeed configuration.

Learn more about installing PageSpeed or enabling Optimize for Bandwidth.
[1] If you're using a different web server, consider running PageSpeed on an Apache or Nginx proxy.  And it's all open source, with porting efforts underway for IIS, ATS, and others.

Posted by Mano Marks, Google Developer Platform Team
Categories: Programming

Hangout Interview

NOOP.NL - Jurgen Appelo - Thu, 09/04/2014 - 15:25

Mads Troels Hansen had a some challenging questions for me in this hangout, such as…

“How do your introduce change in large organizations?”

Oh boy…

The post Hangout Interview appeared first on NOOP.NL.

Categories: Project Management

TypeScript Mario

Phil Trelford's Array - Thu, 09/04/2014 - 08:23

Earlier this year I had a play with Microsoft’s new compile to JavaScript language, TypeScript. Every man and his dog has a compile to JavaScript solution these days. TypeScript’s angle appears to be to provide optional static typing over JavaScript and some ES6 functionality while compiling out to ES3 by default. It provides a class based syntax similar to C#’s and seems to be aimed at developer’s attempting to scale out JavaScript based solutons.

Last year I ported Elm’s Mario sample to F#, which ended up looking similarly concise. I tried both FunScript and WebSharper for compiling F# to JavaScript, and both worked well:


So I thought I’d try the sample out in TypeScript as a way to get a feel for the language.

TypeScript Interfaces

In F# I defined a type for Mario using a record:

// Definition 
type mario = { x:float; y:float; vx:float; vy:float; dir:string }
// Instantiation 
let mario = { x=0.; y=0.; vx=0.; vy=0.; dir="right" }

In TypeScript I used an interface which looks pretty similar syntactically:

// Definition
interface Character {
    x: number; y: number; vx: number; vy: number; dir: string
// Instantiation
var mario = { x:0, y:0, vx:0, vy:0, dir:"right" };

TypeScript transcompiles this to a JavaScript associative array using object notation:

var mario = { x: 0, y: 0, vx: 0, vy: 0, dir: "right" };


For me the cute part of the Elm and F# versions was using the record “with” syntax and function composition, i.e.

let jump (_,y) m = if y > 0 && m.y = 0. then  { m with vy = 5. } else m
let gravity m = if m.y > 0. then { m with vy = m.vy - 0.1 } else m
let physics m = { m with x = m.x + m.vx; y = max 0. (m.y + m.vy) }
let walk (x,_) m = 
    { m with vx = float x 
             dir = if x < 0 then "left" elif x > 0 then "right" else m.dir }

let step dir mario = mario |> physics |> walk dir |> gravity |> jump dir

I couldn’t fine either of those features available out-of-the-box in TypeScript so I resorted to imperative code with mutation and procedures:

function walk(velocity: CursorKeys.Velocity, character: Character) {
    character.vx = velocity.x;
    if (velocity.x < 0) character.dir = "left";
    else if (velocity.x > 0) character.dir = "right";

function jump(velocity:CursorKeys.Velocity, character:Character) {
    if (velocity.y > 0 && character.y == 0) character.vy = 5;    

function gravity(character: Character) {
    if (character.y > 0) character.vy -= 0.1;

function physics(character: Character) {
    character.x += character.vx;
    character.y = Math.max(0, character.y + character.vy);

function verb(character: Character): string {
    if (character.y > 0) return "jump";
    if (character.vx != 0) return "walk";
    return "stand";

function step(velocity: CursorKeys.Velocity, character:Character) {
    walk(velocity, mario);
    jump(velocity, mario);

The only difference between the TypeScript and the resultant JavaScript is the type annotations.

HTML Canvas

TypeScript provides typed access to JavaScript libraries via type definition files. The majority appear to be held on a personal github repository.

Note: both FunScript and WebSharper can make use of these type definition files to provide types within F# too.

Among other things this lets you get typed access over things like the HTML canvas element albeit with some funky casts:

    var canvas = <HTMLCanvasElement> document.getElementById("canvas");
    canvas.width = w;
    canvas.height = h;

This has some value, but you do have to rely on the definition files being kept up-to-date.


On the functional reactive side TypeScript didn't appear to offer much value add in comparison to Elm or F#.

To be honest, for a very small app, I couldn’t find any advantages to using TypeScript over vanilla JavaScript. I guess I’d need to build something a lot bigger to find any.

Sample source code:

Categories: Programming

Minimum Credible Release (MCR) and Minimum Viable Product (MVP)

A Minimum Credible Release, or MCR, is simply the minimal set of user stories that need to be implemented in order for the product increment to be worth releasing.

I don’t know exactly when Minimum Credible Release became an established practice, but I do know that we were using Minimum Credible Release as a concept back in the early 2000’s on the Microsoft patterns & practices team.  It’s how we defined the minimum scope for our project releases.

The value of the Minimum Credible Release is that it provides a baseline for the team to focus on so they can ship.   It’s a metaphorical “finish line.”   This is especially important when the team gets into the thick of things, and you start to face scope creep.

The Minimum Credible Release is also a powerful tool when it comes to communicating to stakeholders what to expect.   If you want people to invest, they need to know what to expect in terms of the minimum bar that they will get for their investment.

The Minimum Credible Release is also the hallmark of great user experience in action.  It takes great judgment to define a compelling minimal release.

A sample is worth a thousand words, so here is a visual way to think about this.  

Let’s say you had a pile of prioritized user stories, like this:


You would establish a cut line for your minimum release:


Note that this is an over-simplified example to keep the focus on the idea of a list of user stories with a cut line.

And the art part is in where and how you draw the line for the release.

While you would think this is such a simple, obvious, and high-value practice, not everybody does it.

All too often there are projects that run for a period of time without a defined Minimum Credible Release.   They often turn into never-ending projects or somebody’s bitter disappointment.   If you get agreement with users about what the Minimum Credible Release will be, you have a much better chance of making your users happy.  This goes for stakeholders, too.

There is another concept that, while related, I don’t think it’s the same thing.

It’s Minimum Viable Product, or MVP.

Here is what Eric Ries, author of The Lean Startup, says about the Minimum Viable Product:

“The idea of minimum viable product is useful because you can basically say: our vision is to build a product that solves this core problem for customers and we think that for the people who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.

So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.”

And, here is what Josh Kaufman, author of The Personal MBA, has to say about the Minimum Viable Product:

“The Lean Startup provides many strategies for validating the worth of a business idea. One core strategy is to develop a minimum viable product – the smallest offer you can create that someone will actually buy, then offer it to real customers. If they buy, you’re in good shape. If your original idea doesn’t work, you simply ‘pivot’ and try another idea.”

So if you want happier users, better products, reduced risk, and more reliable releases, look to Minimum Credible Releases and Minimum Viable Products.

You Might Also Like

Continuous Value Delivery the Agile Way

How Can Enterprise Architects Drive Business Value the Agile Way?

How To Use Personas and Scenarios to Drive Adoption and Realize Value

Categories: Architecture, Programming

A Project Sponsor Isn’t A Project Manager, Scrum Master or Product Owner!

Don't fall into the trap of assuming that the project sponsor can fill all roles.

Don’t fall into the trap of assuming that the project sponsor can fill all roles.

Project sponsors play a critical role in all projects. Sponsor’s  typically are senior leaders in an organization with operational roles that make playing multiple roles on a project difficult at best.  Project sponsors have the bandwidth to take on the project sponsor role, their day job and no other project role, therefore project sponsors are not project managers, Scrum masters or product owners.

Project managers develop plans, report and track progress, assign work and manage resources. Sponsors, on the other hand, provide direction and access to resources. Sponsors are informed by the project manager. On large or medium sized projects, the project manager role is generally a full-time position while the sponsor (generally a member of senior management) spends the majority of his or her time managing a portion of the business rather than a specific project.

In Agile projects the roles of the project sponsor and Scrum master are sometimes confused. A Scrum master facilitates the team. The Scrum master continuously interacts with the team ironing out the interpersonal conflicts, focusing the team on the flow of work and ensuring that nothing blocks the team from achieving their sprint goals. The sponsor provides motivation and exposure for the team at a higher level. A sponsor has issues and blockages escalated to them when they are outside of the team’s span of control. As with the project manager role, the Scrum master’s role provides intimate day-to-day, hour-to-hour support for the team while the sponsor is involved when needed or called upon.

Rarely is the sponsor the product owner. The only time I have seen the two roles combined is in very small organizations or in very small projects (and it wasn’t a great idea in either case). While both roles represent the voice of the business and the organization, a sponsor typically brings significantly more hierarchical power to the table. This positional power tends to dampen important Agile behaviors such as collaboration and self-organization. The product owner role will draw significantly on the time and focus of the project sponsor, which can cause them to take their eye off the direction of the business having negative ramifications.

As noted in The Role of The Project Sponsor, sponsors provide teams with a goal or vision, with access to resources and the political support needed to stay focused. The role can’t be played well by those in the organization without the needed sources of power, interest and resources needed to empower the project. Nor can someone play the role without the time needed to invest in the role. Project sponsors are typically senior leaders within an organization that are tied closely to the day-to-day operations of the organization, which makes it difficult if not impossible for them to play the role of project manager, Scrum master or product owner.

Categories: Process Management

Standard Flavored Markdown

Coding Horror - Jeff Atwood - Wed, 09/03/2014 - 21:06

In 2009 I lamented the state of Markdown:

Right now we have the worst of both worlds. Lack of leadership from the top, and a bunch of fragmented, poorly coordinated community efforts to advance Markdown, none of which are officially canon. This isn't merely incovenient for anyone trying to find accurate information about Markdown; it's actually harming the project's future.

In late 2012, David Greenspan from Meteor approached me and proposed we move forward, and a project crystallized:

I propose that Stack Exchange, GitHub, Meteor, Reddit, and any other company with lots of traffic and a strategic investment in Markdown, all work together to come up with an official Markdown specification, and standard test suites to validate Markdown implementations. We've all been working at cross purposes for too long, accidentally fragmenting Markdown while popularizing it.

We formed a small private working group with key representatives from GitHub, from Reddit, from Stack Exchange, from the open source community. We spent months hashing out the details and agreeing on the necessary changes to turn Markdown into a language you can parse without feeling like you just walked through a sewer – while preserving the simple, clear, ASCII email inspired spirit of Markdown.

We really struggled with this at Discourse, which is also based on Markdown, but an even more complex dialect than the one we built at Stack Overflow. In Discourse, you can mix three forms of markup interchangeably:

  • Markdown
  • HTML (safe subset)
  • BBCode (subset)

Discourse is primarily a JavaScript app, so naturally we needed a nice, compliant implementation of Markdown in JavaScript. Surely such a thing exists, yes? Nope. Even in 2012, we found zero JavaScript implementations of Markdown that could pass the only Markdown test suite I know of, MDTest. It isn't authoritative, it's a community created initiative that embodies its own decisions about rendering ambiguities in Markdown, but it's all we've got. We contributed many upstream fixes to markdown.js to make it pass MDTest – but it still only passes in our locally extended version.

As an open source project ourselves, we're perfectly happy contributing upstream code to improve it for everyone. But it's an indictment of the state of the Markdown ecosystem that any remotely popular implementation wasn't already testing itself against a formal spec and test suite. But who can blame them, because it didn't exist!

Well, now it does.

It took a while, but I'm pleased to announce that Standard Markdown is now finally ready for public review.

It's a spec, including embedded examples, and implementations in portable C and JavaScript. We strived mightily to stay true to the spirit of Markdown in writing it. The primary author, John MacFarlane, explains in the introduction to the spec:

Because Gruber’s syntax description leaves many aspects of the syntax undetermined, writing a precise spec requires making a large number of decisions, many of them somewhat arbitrary. In making them, I have appealed to existing conventions and considerations of simplicity, readability, expressive power, and consistency. I have tried to ensure that “normal” documents in the many incompatible existing implementations of markdown will render, as far as possible, as their authors intended. And I have tried to make the rules for different elements work together harmoniously. In places where different decisions could have been made (for example, the rules governing list indentation), I have explained the rationale for my choices. In a few cases, I have departed slightly from the canonical syntax description, in ways that I think further the goals of markdown as stated in that description.

Part of my contribution to the project is to host the discussion / mailing list for Standard Markdown in a Discourse instance.

Fortunately, Discourse itself just reached version 1.0. If the only thing Standard Markdown does is help save a few users from the continuing horror that is mailing list web UI, we all win.

What I'm most excited about is that we got a massive contribution from the one person who, in my mind, was the most perfect person in the world to work on this project: John MacFarlane. He took our feedback and wrote the entire Standard Markdown spec and both implementations.

A lot of people know of John through his Pandoc project, which is amazing in its own right, but I found out about him because he built Babelmark. I learned to refer to Babelmark extensively while working on Stack Overflow and MarkdownSharp, a C# implementation of Markdown.

Here's how crazy Markdown is: to decide what the "correct" behavior is, you provide sample Markdown input to 20+ different Markdown parsers … and then pray that some consensus emerges in all their output. That's what Babelmark does.

Consider this simple Markdown example:

# Hello there

This is a paragraph.

- one
- two
- three
- four

1. pirate
2. ninja
3. zombie

Just for that, I count fifteen different rendered outputs from 22 different Markdown parsers.

In Markdown, we literally built a Tower of Babel.

Have I mentioned that it's a good idea for a language to have a formal specification and test suites? Maybe now you can see why that is.

Oh, and in his spare time, John is also the chair of the department of philosophy at the University of California, Berkeley. No big deal. While I don't mean to minimize the contributions of anyone to the Standard Markdown project, we all owe a special thanks to John.

Markdown is indeed everywhere. And that's a good thing. But it needs to be sane, parseable, and standard. That's the goal of Standard Markdown — but we need your help to get there. If you use Markdown on a website, ask what it would take for that site to become compatible with Standard Markdown; when you see the word "Markdown" you have the right to expect consistent rendering across all the websites you visit. If you implement Markdown, take a look at the spec, try to make your parser compatible with Standard Markdown, and discuss improvements or refinements to the spec.

Update: The project was renamed CommonMark. See my subsequent blog post.

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!
Categories: Programming

SEMAT: The Essence of Software Engineering

From the Editor of Methods & Tools - Wed, 09/03/2014 - 17:37
SEMAT (Software Engineering Method and Theory) is an initiative to reshape software engineering such that software engineering qualifies as a rigorous discipline. SEMAT and Essence are big thinking for software developers. There are millions of software engineers on the planet in countless programs, projects and teams; the millions of line of software that run the world are testament to their talents, but as community we still find it difficult to share our best practices, truly empower our teams, seamless integrate software engineering into our businesses, and maintain the health of our ...

Strategy: Change the Problem

James T. Kirk's infamous gambit in Starfleet's impossible to win Kobayashi Maru test was to redefine the problem into a challenge he could beat. 

Interestingly, an article titled Shifts In Algorithm Design, says something like the same gambit is the modern method of solving algorithmic problems.

In the past: 

I, Dick, recall the “good old days of theory.” When I first started working in theory—a sort of double meaning—I could only use deterministic methods. I needed to get the exact answer, no approximations. I had to solve the problem that I was given—no changing the problem.


In the good old days of theory, we got a problem, we worked on it, and sometimes we solved it. Nothing shifty, no changing the problem or modifying the goal. 

Categories: Architecture