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

Are You Doing Agile Results?

If you already use Agile Results as your personal results system, you have a big advantage.

Why?

Because most people are running around, scrambling through a laundry list of too many things to do, a lack of clarity around what the end result or outcomes should be, and a lack of clarity around what the high-value things to focus on are.  They are using their worst energy for their most important things.  They are spending too much time on the things that don’t matter and not enough time on the things that do.   They are feeling at their worst, when they need to feel at their best, and they are struggling to keep up with the pace of change.

I created Agile Results to deal with the chaos in work and life, as a way to rise above the noise, and to easily leverage the most powerful habits and practices for getting better results in work and life.

Agile Results, in a nutshell, is a simple system for mastering productivity and time management, while at the same time, achieving more impact, realizing your potential, and feeling more fulfillment.

I wrote about the system in the book Getting Results the Agile Way.  It’s been a best seller in time management.

How Does Agile Results Work?

Agile Results works by combining proven practices for productivity, time management, psychology, project management, and some of the best lessons learned on high-performance.   And it’s been tested for more than a decade under extreme scenarios and a variety of conditions from individuals to large teams.

Work-Life balance is baked into the system, but more importantly Agile Results helps you live your values wherever you are, play to your strengths, and rapidly learn how to improve your results in an situation.  When you spend more time in your values, you naturally tap into your skills and abilities that help bring out your best.

The simplest way to think of Agile Results is that it helps you direct your attention and apply your effort on the things that count.  By spending more time on high-value activities and by getting intentional about your outcomes, you dramatically improve your ability to get better results.

But none of that matters if you aren’t using Agile Results.

How Can You Start Using Agile Results?

Start simple.

Simply ask yourself, “What are the 3 wins, results, or outcomes that I want for today?.”   Consider the demands you have on your plate, the time and energy you’ve got, and the opportunities you have for today, and write those 3 things down.

That’s it.   You’re doing Agile Results.

Of course, there’s more, but that’s the single most important thing you can do to immediately gain clarity, regain your focus, and spend your time and energy on the most valuable things.

Now, let’s assume this is the only post you ever read on Agile Results.   Let’s take a fast walkthrough of how you could use the system on a regular basis to radically and rapidly improve your results on an ongoing basis.

How I Do Agile Results? …

Here’s a summary of how I do Agile Results.

I create a new monthly list at the start of each month that lists out all the things that I think I need to do, and I bubble up 3 of my best things I could achieve or must get done to the top.   I look at it at the start of the week, and any time I’m worried if I’m missing something.  This entire process takes me anywhere from 10-20 minutes a month.

I create a weekly list at the start of the week, and I look at it at the start of each day, as input to my 3 target wins or outcomes for the day, and any time I’m worried if I’m missing anything.   This tends to take me 5-10 minutes at the start of the week.

I barely have to ever look at my lists – it’s the act of writing things down that gives me quick focus on what’s important.   I’m careful not to put a bunch of minutia in my lists, because then I’d train my brain to stop focusing on what’s important, and I would become forgetful and distracted.  Instead, it’s simple scaffolding.

Each day, I write a simple list of what’s on my mind and things I think I need to achieve.   Next, I step back and ask myself, “What are the 3 things I want to accomplish today?”, and I write those down.   (This tends to take me 5 minutes or less.  When I first started it took me about 10.)

Each Friday, I take the time to think through three things going well and three things to improve.   I take what I learn as input into how I can simplify work and life, and how I can improve my results with less effort and more effectiveness.   This takes me 10-20 minutes each Friday.

How Can You Adopt Agile Results?

Use it to plan your day, your week, and your month.

Here is a simple recipe for adopting Agile Results and using it to get better results in work and life:

  1. Add a recurring appointment on your calendar for Monday mornings.  Call it Monday Vision.   Add this text to the body of the reminder: “What are your 3 wins for this week?”
  2. Add a recurring appointment on your calendar to pop up every day in the morning.  Call it Daily Wins.  Add this text to the body of the reminder: “What are your 3 wins for today?”
  3. Add a recurring appointment on your calendar to pop up every Friday mid-morning.  Call it Friday Reflection.  Add this text to the body of your reminder:  What are 3 things going well?  What are 3 things to improve?”
  4. On the last day of the month, make a full list of everything you care about for the next month.   Alphabetize the list.  Identify the 3 most important things that you want to accomplish for the month, and put those at the top of the list.   Call this list  Monthly Results for Month XYZ.  (Note – Alphabetizing your list helps you name your list better and sort your list better.  It’s hard to refer to something important you have to do if you don’t even have a name for it.  If naming the things on your list and sorting them is too much to do, you don’t need to.  It’s just an additional tip that helps you get even more effective and more efficient.)
  5. On Monday of each week, when you wake up, make a full list of everything you care about accomplishing for the week.  Alphabetize the list.  Identify the 3 most important things you want to accomplish and add that to the top of the list.  (Again, if you don’t want to alphabetize then don’t.)
  6. On Wednesdays, in the morning, review the three things you want to accomplish for the week to see if anything matters that you should have spent time on or completed by now.  Readjust your priorities and focus as appropriate.  Remember that the purpose of having the list of your most important outcomes for the week isn’t to get good at predicting what’s important.  It’s to help you focus and to help you make better decisions about what to spend time on throughout the week.  If something better comes along, then at least you can make a conscious decision to trade up and focus on that.  Keep trading up.   And when you look back on Friday, you’ll know whether you are getting better at trading up or if you are just getting randomize or focusing on the short-term but hurting the long term.
  7. On Fridays,  in the morning, do your Friday Reflection.  As part of the exercise, check against your weekly outcomes and your monthly outcomes that you want to accomplish.  If you aren’t effective for the week, don’t ask “why not,” ask “how to.”   Ask how can you bite off better things and how can you make better choices throughout the week.  Just focus on little behavior changes, and this will add up over time.  You’ll get better and better as you go, as long as you keep learning and changing your approach.   That’s the Agile Way.

There are lots of success stories by other people who have used Agile Results.   Everybody from presidents of companies to people in the trenches, to doctors and teachers, to teams and leaders, as well as single parents and social workers.

But none of that matters if it’s not your story.

Work on your success story and just start getting better results, right here, right now.

What are the three most important things you really want to accomplish or achieve today?

Categories: Architecture, Programming

Stuff The Internet Says On Scalability For August 8th, 2014

Hey, it's HighScalability time:


Physicists reveal the scaling behaviour of exotic giant molecules.
  • 5 billion: Transistors Intel manufactures each second; 396M: WeChat active users
  • Quotable Quotes:
    • @BenedictEvans: Every hour or so, Apple ships phones with something around 2x more transistors than were in all the PCs on earth in 1995.
    • @robgomes: New client. Had one of their employees tune an ORM-generated query. Reduced CPU by 99.999%, IO by 99.996%.  Server now idle.
    • @pbailis: As a hardware-oriented systems builder, I'd pay attention to, say, ~100 ns RTTs via on-chip photonic interconnects
    • @CompSciFact: "Fancy algorithms are buggier than simple ones, and they're much harder to implement." -- Rob Pike's rule No. 4
    • @LusciousPear: I'm probably doing in Google what would have taken 5-8 engineers on AWS.
    • C. Michael Holloway, NASA: To a first approximation, we can say that accidents are almost always the result of incorrect estimates of the likelihood of one or more things.
    • Stephen O'Grady: More specific to containers specifically, however, is the steady erosion in the importance of the operating system. 

  • Wait, I thought mobile meant making single purpose apps? Mobile meant tearing down the portal cathedrals built by giants of the past. Then Why aren’t App Constellations working?: The App Constellation strategy works when you have a core resource which can be shared across multiple apps. 

  • Decentralization: I Want to Believe. The irony is mobile loves centralization, not p2p. Mobile IP addresses change all the time and you can't run a server on a phone. The assumption that people want decentralization has been disproven. Centralized services have won. People just want a service that works. The implementation doesn't matter that much. Good discussion on HackerNews and on Reddit.

  • Myth: It takes less money to start a startup these days. Sort of.  Why the Structural Changes to the VC Industry Matter: It turns out that, while it is in fact cheaper to get started and enter the market, it also requires more money for the breakout companies to win the market. Ultimately, today’s winners have a chance to be a lot bigger. But winning requires more money for geographic expansion, full-stack support of multiple new disciplines, and product expansion. And these companies have to do all of this while staying private for a much longer period of time; the median for money raised by companies prior to IPO has doubled in the past five years. 

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

Extending AngularJS services with the Decorate method

Xebia Blog - Fri, 08/08/2014 - 12:00

Many large Angular applications tend to see a lot of repetition - same API endpoint, same method of dealing with and transforming data, etcetera. One technique you can use to at least alleviate that is using AngularJS's decorate method, which allows you to extend, adjust or even fully replace any existing service.

As you'll see in this post, using this allows you to modify and extend the framework you build your app in, which will lead to a cleaner, more legible codebase, written in a more functional style (the what, not the how).

Update 11/8: The follow-up is now live, along with the GitHub repository.

A feature not often used when developing AngularJS applications is the $provide service, which is the primary service used to register components with the $injector. More commonly, a developer would use methods like $provide.service() or $provide.factory to do so, but those are merely utility methods defined in the $provide service and exposed via angular.module().

The main reasons to use $provide over the service() and factory() methods is to configure the service before it's instantiated, for example. While there may be more advanced use-cases for using $provide, I haven't yet encountered them while developing regular applications and I'm sure they won't occur often.

One of the methods listed at the very bottom of the $provide documentation is the decorate() method. It doesn't look like much (it's at the bottom, after all), but its documentation hints that it's very powerful:

"A service decorator intercepts the creation of a service, allowing it to override or modify the behaviour of the service. The object returned by the decorator may be the original service, or a new service object which replaces or wraps and delegates to the original service."

Nothing to add there. You can use decorate() to change, add to, or completely replace the behaviour of services without having to edit its code. This can be done on any code not your own - core AngularJS services, but also third-party libraries. It's the equivalent of overriding methods in OO languages or monkey-patching in the more dynamic languages.

“Isn’t that evil?”, I hear you ask. As with every programming-related question, the only correct answer is: it depends. I’m going to give a few practical examples of when I believe using decorate() is appropriate. In a future blog post, I'll expand on this example, showing how relatively simple code can positively influence your entire application architecture.

Here’s a practical example, a neat follow-up on my previous blog about angular promises: decorating $q to add methods to the promise object. The promise API itself defines only one method: then(). $q adds a few simple methods to that like catch() and finally(), but for your own application you can add a few more.

If you’ve been working with promises for a little while in your AngularJS application, you’ve probably noticed some operations are pretty common; assigning the promise result to the scope (or any object), logging the result in the console, or calling some other method. Using decorate(), we can add methods to the promise object to simplify those. Here's a bit of code from my previous post; we'll add a method to $q to remove the need for a callback:

CustomerService.getCustomer(currentCustomer)
 .then(CartService.getCart)
 .then(function(cart) {
   $scope.cart = cart;
 })
 .catch($log.error);

First, we’ll need to do some boilerplate: we create a function that adds our methods to the promise object, and then we replace all the default promise methods. Note that the decorating function will also apply itself to the given promise.then method again, so that our customisations aren’t lost further down a promise chain:

angular.module('ngPromiseDsl', [])
  .config(function ($provide) {
    $provide.decorator('$q', function ($delegate, $location) {

      // decorating method

      function decoratePromise(promise) {
        var then = promise.then;

        // Overwrite promise.then. Note that $q's custom methods (.catch and .finally) are implemented by using .then themselves, so they're covered too.

        promise.then = function (thenFn, errFn, notifyFn) {
          return decoratePromise(then(thenFn, errFn, notifyFn));
        };

        return promise;
      }

      // wrap and overwrite $q's deferred object methods

      var defer = $delegate.defer,
        when = $delegate.when,
        reject = $delegate.reject,
        all = $delegate.all;

      $delegate.defer = function () {
        var deferred = defer();
        decoratePromise(deferred.promise);
        return deferred;
      };

      $delegate.when = function () {
        return decoratePromise(when.apply(this, arguments));
      };

      $delegate.reject = function () {
        return decoratePromise(reject.apply(this, arguments));
      };

      $delegate.all = function () {
        return decoratePromise(all.apply(this, arguments));
      };

      return $delegate;

    });
  });

With that boilerplate in place, we can now start adding methods. As I mentioned earlier, one of the most common uses of a then() function is to set the result onto the scope (or some other object). This is a fairly trivial operation, and it’s pretty straightforward to add it to the promise object using our decorator, too:

function decoratePromise(promise) {
  var then = promise.then;

  promise.then = function (thenFn, errFn, notifyFn) {
    return decoratePromise(then(thenFn, errFn, notifyFn));
  };

  // assigns the value given to .then on promise resolution to the given object under the given varName
  promise.thenSet = function (obj, varName) {
    return promise.then(function (value) {
      obj[varName] = value;
      return value;
    });
  };

  return promise;
}

That’s all. Put this .config block in your application's module definition, or create a new module and add a dependency to it, and you can use it throughout your application. Here's the same piece of code, now with our new thenSet method:

CustomerService.getCustomer(currentCustomer)
  .then(CartService.getCart)
  .thenSet($scope, 'cart')
  .catch($log.error);

This particular example can be extended in a multitude ways to add useful utilities to promises. In my current project we’ve added a number of methods to the promise object, which allows us to reduce the number of callback definitions in our controllers and thus create cleaner, more legible code.

 

Replacing custom callbacks with named methods allows for a more functional programming style, and allows readers to read and write code as a list of “whats”, instead of “hows” - and it's also fully asynchronous.

Extending $q is just the start though: Every angular service can be extended for various purposes - add performance monitoring and logging to $http, set common prefixes or fixed properties on $resource urls or template paths, you name it. Leave a remark in the comments about how you've used decorate() to create a better application.

Stay tuned for an upcoming post where I release a small open source project that extends angular’s promise objects with a number of helpful methods to perform common tasks.

Further reading, resources, helpful links:

Seven Deadly Sins of Metrics Programs: Greed

Greed is taking all the food and not leaving some for everyone else.

Greed is taking all the food and not leaving some for everyone else.

Greed, in metrics programs, means allowing metrics to be used as a tool to game the system to gain more resources than one needs or deserves.  At that point measurement programs start down the path to abandonment. The literature shows that greed, like envy, is affected by a combination of personal and organizational attributes.   Whether the root of the problem is nature or nurture, organizational culture can make the incidence of greed worse and that is something we can do something about.

One of the critical cultural drivers that create a platform for greed is fear.  W. Edward Deming in his famous 14 Principles addressed fear: “Drive out fear, so that everyone may work effectively for the company.” Fear is its own disease, however combined with an extremely competitive culture that stresses win/lose transactions, it creates an atmosphere that causes greed to become an economically rational behavior.  Accumulating and hoarding resources reduces your internal competitors’ ability to compete and reduces the possibility of losing because of lack of resources.  Fear-driven greed creates its own insidious cycle of ever increasing fear as the person infected with greed fears that their resource horde is at risk and requires defense (attributed to Sun Tzu in the Art of War). An example of the negative behaviors caused by fear that I recently heard about was a company that had announced that they cull the lower ten percent of the organization annually at the beginning of last year.  Their thought was that completion would help them identify the best and the brightest.  In a recent management meeting the person telling the story indicated that the CIO had expressed exasperation with projects that hadn’t shared resources and that there were cases in which personnel managers had actively redirected resources to less critical projects.

Creating an atmosphere that fosters greed can generate a whole host of bad behaviors including:

  1. Disloyalty
  2. Betrayal
  3. Hoarding
  4. Cliques/silos
  5. Manipulation of authority

Coupling goals, objectives and bonuses to measures in your metrics program can induce greed and have a dramatic effect on many of the other Seven Deadly Sins. For example, programs that have wrestled with implementing a common measure of project size and focused on measuring effectiveness and efficiency will be able to highlight how resources are used.  Organizations that then set goals that based on comparing team effectiveness and efficiency will create an environment in which hoarding resources generate a higher economic burden on the hoarder, because it reduces the efficiency of other teams.  That potential places a burden on a measurement program to create an environment where greed is less likely to occur.

Measurement programs can help create an atmosphere that defuses greed by providing transparency and accountability for results. Alternately as we have seen in earlier parts of this essay, poor measurement programs can and do foster a wide range of poor behaviors.


Categories: Process Management

Process is King

Herding Cats - Glen Alleman - Thu, 08/07/2014 - 18:35

The notion of self-directed development teams has a range of applicable domains. Much of the rancor around agile development these days is about how to apply the core principles of agile software development. Do we need estimates? What's the role of business process in the development life cycle? How are capabilities and requirements elicited? Who has what decision rights for what decisions? How can we made these decisions and what information is needed in order to make the decisions?

Guy Strelitz's post has got me thinking about the spectrum of the world called agile. Here's my take on his diagram. Working in a domain where we're spending other people's money, lots of other people's money, the Winging it approach is simply not accepted. The Kanban approach doesn't either because the inter-dependencies between the backlog items it tight, so picking the next thing off the blog log based on business value may not be possible, since some pre-condition may need to be fulfilled before a higher value item can be started. Softwarr development is not production in our domain. Kanban is a production flow management system, no matter how twisted the logic of the Kanban software advocates make it out to be.

Scrum is a powerful approach to emergent requirements. With those requirements anchored to Needed Capabilities. Capabilities that all have to be in place for the system to be called ready for Go Live. Some more formality is needed as governance and regulatory paradigms are encountered.

Finally we arrive at the Enterprise model of software development. The firm depends on the software system for revenue. PayPal depends on the system for revenue, but not in the way an insurance company does. Or a gas pipeline process control system does. 

But at the same time, agile can contribute to not only increasing the probability of project success, but also deal with the emerging requirements traceable to the need capabilities.

Screen Shot 2014-08-06 at 11.37.15 AM

Process is King

So not to the point. In that agile enterprise paradigm, the mission critical aspects of the software system demand assuance that the released software is not only Fit for Purpose and it is Fit for Use. That is, the software does what it is supposed to do, in a way it is supposed to work. 

One of the critically important process of any enterprise software system is the Change Control (CC) and Release Management (RM) process. The software system is a corporate asset and must be treated as such. This asset is carried on the General Ledger as an asset. A capital investment, governed by the rules of accounting for capital assets. That's essentially the definition of enterprise

In this enterprise paradigm, the control of these assets starts with CC and RM. Here's a high level flow of how this corporate asset is managed. In this example development occurs in the lower left. The CC and RM process is post development. This development business rhythm can be weekly, monthly, possibly even daily. But once the software is ready for release to production, this is a possible process. 

The key here is separation of concerns. The developers of enterprise software our not the approvers of the release of that software, nor are they the involved in the QA, UAT, and Performance Assessment of that software.

Screen Shot 2014-08-06 at 11.33.30 AM

So this is the separation from the activities on the left of the top diagram to those on the right. When some suggests a new idea, or has read a book about a new idea and wants to discuss it - ask where on the spectrum of the top diagram they work, where they think their idea would fit in.

In the End

Without first starting with a domain, context, framing assumptions around governance, established decision rights any suggested process has no home for being tested against reality.

Related articles Performance Based Management Agile Project Management Kanban is the New Scrum Can Enterprise Agile Be Bottom Up? Agile Paradigm The Myth of Incremental Development
Categories: Project Management

Google Fit Preview SDK now available

Google Code Blog - Thu, 08/07/2014 - 18:00
By Angana Ghosh, Product Manager, Google Fit

At Google I/O we announced Google Fit: an open platform for developers to more easily build fitness apps. Today we’re making a preview SDK available to developers so that you can start to build.

Google Fit provides a single set of APIs for apps and device manufacturers to store and access activity data from fitness apps and sensors on Android and other devices (like wearables, heart rate monitors or connected scales). This means that with the user’s permission, you can get access to the user’s fitness history -- enabling you to provide more interesting features in your app like personalized coaching, better insights, fitness recommendations and more.

There are three sets of APIs designed to meet specific developer needs:
  1. Sensors API provides high-level access to sensors from the device and wearables—so with one API your app can talk to sensors, whether on an Android device or a wearable. So if you’re making a running app, you could register it to receive updates from a connected heart rate monitor every 5 seconds during a user’s run and give immediate feedback to the runner on the display.
  2. Recording API allows apps to register for battery-efficient, cloud-synced background collection of fitness data. For example, a running app could ask to store user’s location so it can map the run later. Once it registers for these data types, collection is done by Fit in the background with no further work needed by the app.
  3. History API allows operations on the data like read, insert and delete. When the exerciser finishes her run, the running app can query the History API for all locations during the run and show a map.
To get started, download the updated version of Google Play services containing the Google Fit APIs for Android in the Android L Developer Preview Nexus 5 and Nexus 7 system images. Use the Android SDK Manager to download the Google Play services client labeled "Google Play services for Fit Preview". You can start developing today using local fitness history on the device — the cloud backend will be available soon. Join the Google Fit developer community on Google+ to discuss the Preview and ask questions. For additional resources and more information about Google Fit, check out the Google Fit developers site.

The preview SDK gives you the tools to start building your app. You’ll be able to launch your app later this year when we launch the full Google Fit SDK as part of Google Play services for handsets, Android Wear and also for the web. We’re excited to see what you can come up with to make fitness in a connected world better.


Join the discussion on
+Google Fit Developers
Angana Ghosh is a product manager for the Google Fit team.

Posted by Louis Gray, Googler
Categories: Programming

The Principles of Modern Management

Are your management practices long in the tooth?

I think I was lucky that early on, I worked in environments that shook things up and rattled the cage in pursuit of more customer impact, employee engagement, and better organizational performance.

In one of the environments, a manufacturing plant, the management team flipped the typical pyramid of the management hierarchy upside down to reflect that the management team is there to empower and support the production line.

And when I was on the Microsoft patterns & practices team, we had an interesting mix of venture capitalist type management coupled with some early grandmasters of the Agile movement.   More than just Agile teams, we had an Agile management culture that encouraged a customer-connected approach to product development, complete with self-organizing, multi-disciplinary teams, empowered people, a focus on execution excellence, and a fierce focus on being a rapid learning machine. 

We thrived on change.

We also had a relentless focus on innovation.  Not just in our product, but in our process.  If we didn’t innovate in our process, then we got pushed out of market by becoming too slow, too expensive, or by lacking the quality experience that customers have come to expect.

But not everybody knows what a great environment for helping people thrive and do great things for the world, looks like.

While a lot of people in software or in manufacturing have gotten a taste of Agile and Lean practices, there are many more businesses that don’t know what a modern learning machine of people and processes that operate at a higher-level looks like. 

Many, many businesses and people are still operating and looking at the world through the lens of old world management principles.

In the book The Future of Management, Gary Hamel walks through the principles upon which modern management is based.

The Principles of Modern Management

Hamel gives us a nice way to frame looking at the modern management principles, by looking at their application, and their intended goal.

Via The Future of Management:

Principle Application Goal Standardization Minimize variances from standards around inputs, outputs, and work methods. Cultivate economies of scale, manufacturing efficiency, reliability, and quality. Specialization (of tasks and functions) Group like activities together in modular organizational units. Reduce complexity and accelerate learning. Goal alignment Establish clear objectives through a cascade of subsidiary goals and supporting metrics. Ensure that individual efforts are congruent with top-down goals. Hierarchy Create a pyramid of authority based on a limited span of control. Maintain control over a broad scope of operations. Planning and control Forecast demand, budget resources, and schedule tasks, then track and correct deviations from plan. Establish regularity and predictability in operations; conformance to plans. Extrinsic rewards Provide financial rewards to individuals and teams for achieving specified outcomes. Motivate effort and ensure compliance with policies and standards. What are the Principles Upon Which Your Management Beliefs are Based?

Most people aren’t aware of the principles behind the management beliefs that they practice or preach.  But before coming up with new ones, it helps to know what current management thinking is rooted in.

Via The Future of Management:

“Have you ever asked yourself, what are the deepest principles upon which your management beliefs are based? Probably not.  Few executives, in my experience, have given much thought to the foundational principles that underlie their views on how to organize and manage.  In that sense, they are as unaware of their management DNA as they are of their biological DNA.  So before we set off in search of new management principles, we need to take a moment to understand the principles that comprise our current management genome, and how those tenets may limit organizational performance.”

A Small Nucleus of Core Principles

It really comes down to a handful of core principles.  These principles serve as the backbone for much of today’s management philosophy.

Via The Future of Management:

“These practices and processes of modern management have been built around a small nucleus of core principles: standardization, specialization, hierarchy, alignment, planning, and control, and the use of extrinsic rewards to shape human behavior.”

How To Maximize Operational Efficiency and Reliability in Large-Scale Organizations

It’s not by chance that the early management thinkers came to the same conclusions.  They were working on the same problems in a similar context.  Of course, the challenge now is that the context has changed, and the early management principles are often like fish out of water.

Via The Future of Management:

“These principles were elucidated early in the 20th century by a small band of pioneering management thinkers -- individuals like Henri Fayol, Lyndall Urwick, Luther Gullick, and Max Weber. While each of these theorists had a slightly different take on the philosophical foundations of modern management, they all agreed on the principles just enumerated. This concordance is hardly surprising, since they were all focusing on the same problem: how to maximize operational efficiency and reliability in large-scale organizations. Nearly 100 years on, this is still the only problem that modern management is fully competent to address.”

If your management philosophy and guiding principles are nothing more than a set of hand me downs from previous generations, it might be time for a re-think.

You Might Also Like

Elizabeth Edersheim on Management Lessons of a Lifelong Student

How Employees Lost Empathy for their Work, for the Customer, and for the Final Product

No Slack = No Innovation

The Drag of Old Mental Models on Innovation and Change

The New Competitive Landscape

The New Realities that Call for New Organizational and Management Capabilities

Who’s Managing Your Company

Categories: Architecture, Programming

What Models Should be Used to Create Requirements in an Agile Project?

Software Requirements Blog - Seilevel.com - Thu, 08/07/2014 - 17:00
This is a question that came up repeatedly in the classes I have taught these past few months.  My answer is always the same – “any and all models that are needed to define the problem space and derive the requirements.”  The reaction to this is almost always identical – “but I thought we ONLY […]
Categories: Requirements

A Valuable Sprint Review (a.k.a. Demo): How To

Xebia Blog - Thu, 08/07/2014 - 10:05

A valuable Sprint Review (from now on in this blog referred to as Demo) can be built in three steps. It starts during the Sprint planning session with agreeing on and understanding the user stories on the Sprint backlog. Then, during the Sprint, the team constantly exchanges ideas and results of the realisation of the Story. Finally, during the demo itself, the Product Owner and the rest of the team demo the stories to the stakeholders to display the value delivered and open up for feedback.

Planning for a good demo

During the planning session, it is imperative that the Product Owner and the rest of the team understand the stories that will be picked up. This sounds obvious, but it happens often that this is not the case. Stories might be too technical so the Product Owner is disconnected or stories are so high level that it is hard to determine what needs to be done.

Make sure stories are formulated from the perspective of an end-user of the functionality that will be delivered. This could be an actual user, a system that picks up whatever result is created or any other manifestation of who or what will use the result of the story.

Also take care of getting the acceptance criteria clear. This way it will be clear to developers what to build, to testers what to test for and designers what to design. It will help the Product Owner to have a better idea what is in and what might have to be defined in a new/other user story.

It is important that everyone understands the context in which the story ‘lives’. What part of the system is touched (end-to-end is preferred but not always possible), which parties are affected by the change, what prerequisites are needed, etc.

Building for a great demo

When during the creation of the value of each story the whole team is in constant contact about intermediate results and decisions taken, everyone will be able to add to the value and be aware of what the result of the story will be. It is very important that the whole team is including the Product Owner. When the PO sees the intermediate results, she or he can already create an image of what the result will be like. Also, the PO can contact stakeholders that might have an opinion of what is created and, when needed, adjust the end result to match expectations.

Delivering an valuable demo

In the demo, the Product Owner should present to the stakeholders the value of each user story that has been delivered. So, per story, explain what has changed from the perspective of the end-user and have the rest of the team show this. Also, when stories are not done, explain which (sub-)functionality is not yet finished. Make sure to ask for feedback from the end-user or other stakeholders on what is demonstrated.

Conclusion

The value of the demo depends largely on the cooperation of the entire team. When the Product Owner and the rest of the team work together on understanding what will be delivered and help each other to get the most value from each story delivered the demo will be focused, valuable and fun.

Seven Deadly Sins of Metrics Programs: Sloth

14545519494_12ab1ba776_kSloth plagues many measurement programs as they age.  As time goes by, it is easy for practitioners to drift away from the passionate pursuit of transforming data into knowledge. Sloth in measurement programs is typically not caused by laziness. Leaders of measurement groups begin as true believers, full of energy. However over time, many programs fall prey to wandering relevance. When relevance is allowed to waiver it is very difficult to maintain the same level of energy as when the program was new and shiny. Relevance can slip away if measurement goals are not periodically challenged and validated. An overall reduction in energy can occur even when goals are synchronized, if there is a conflict on how the data will be used and analyzed between any of the stakeholder classes (measurement team, management or the measured). Your energy will wane if your work results in public floggings or fire drills (at the very least it will make you unpopular).

The drift into sloth may be a reflection of a metrics palette that is not relevant to the organization’s business, therefore not likely to produce revelations that create excitement and interest.  This can cause a cascade of further issues.  Few metrics programs begin life by selecting irrelevant metrics, except by mistake, however over time relevance can wander as goals and organizational needs change.  Without consistent review, relevance will wane and it will be easy for metrics personnel to lose interest and become indifferent and disengaged.

In order to avoid or reclaim your program from sloth due to drifting goals; synchronize measurement goals with the organization goals periodically.  I suggest mapping each measurement goal and measure to the organizations goals.  If a direct link can’t be traced, I suggest that you replace the measure.  Note: measurement goals should be reviewed and validated any time a significant management change occurs.

When usage is the culprit, your job is to counsel all stakeholders on proper usage. However, if management wants to use measurement as a stick, it is their prerogative. Your prerogative is to change fields or to act out and accept the consequences. If the usage is a driver for lack of energy, you probably failed much earlier in the measurement program and turning the ship will be very difficult. Remember that it pays to spend time counseling the organization about how to use measurement data from day one rather than getting trapped in a reactionary mode.

The same symptoms occur when management is either disinterested (not engaged and not disposed positively or negatively toward the topic) or has become uninterested (disengaged). The distinction between disinterested and uninterested is important because the solutions are different. Disinterest requires marketing to find a reason to care; to be connected.  A stakeholder that has become uninterested needs to be reconnected with by providing information so their decisions matter.  Whatever the reason for actively disengaging or losing interest, loosing passion for metrics will sap the vitality of your program and begin a death spiral.  Keep your metrics relevant and that relevance will provide protection against waning interest. Metrics professionals should ensure there is an explicit linkage between your metrics palate and the business goals of your organization.  Periodically audit your metrics program.  As part of the audit map the linkages between each metric and the organizations business goals.  Make sure you are passionate about what you do.  Sharing your passion of developing knowledge and illustrating truth will help generate a community of need and support.

Synchronizing goals, making metrics relevant and instilling passion may not immunize your metrics program from failure but they will certainly stave off the deadly sin of sloth. If you can’t generate passion or generate information and knowledge from the metrics program to generate relevance consider a new position, because in the long run not making the change isn’t really an option..


Categories: Process Management

Scrumban

Xebia Blog - Wed, 08/06/2014 - 19:19

Scrum has become THE revolution in the world of software development. The main philosophy behind scrum is accepting that a problem cannot be fully understood or defined at start; scrum has the focus on maximizing the team's ability to deliver quickly and respond to emerging requirements. It came as truly refreshing in the time when projects were ruled by procedure and MS-project planning. Because of scrum:

  1. Projects can deliver what the customer needs, not just what he thought he wanted.
  2. Teams are efficient. They work as a unit to reach a common goal.
  3. We have better project roles (like a product owner and scrum master), ceremonies (like daily stand-ups, grooming) and a scrumboard.

But the central question is: "are we there yet"? And the answer is: "No!". We can optimize scrum by mixing it with kanban, which leads to scrumban.

A kanban introduction for scrummers

Instead of scrum, which is a software development framework in the widest sense of the term, kanban is a method. It, or instance, does not define ceremonies and project roles. There are two main principles in kanban I would like to highlight:

  1. Each column on the kanban board represents a step in the workflow. So, instead of the lanes 'todo', 'inprogress' and 'done' like in scrum, you have 'defining', 'developing', 'testing' and 'deploying'. That is a more full-stack view; a task has a wider lifecycle. This concept is also called 'from concept to cash'; from user research and strategic planning to data center operations and product support.
  2. Another principle of Kanban is that it limits WIP (work in progress). An example of a WIP limit is limiting the number of cards allowed in each column. The advantage is that it reveals bottlenecks dynamically. Because of the WIP, Kanban is a pull mechanism. For instance, a tester can only pickup a next work item if there are items available in de done-column of development-lane and when the WIP limit of the test-lane isn't exceeded.

After all kanban is incredibly simple, but at the same time incredibly powerful.

What's wrong with scrum?

  1. The reason why we went to scrum is because we did not want the waterfall approach anymore. But, in fact each sprint in scrum has become a mini waterfall. In each sprint teams plan, try to design, develop and test. At the end the product owner reviews the completed work and decides which of the stories are shippable and ready for production. Those sprints can result in a staccato flow, which can be exhausted. With kanban we can make sprints more agile and the goal is to have a more continuous flow. In comparison with how to run a marathon? You don't make sprints of 200 meters, but rather with a constant rate.
  2. Scrum is a push mechanism and therefore 'pushes' the quality out of your product. When a sprint backlog is defined, the team is asked for a commitment. Whatever happened, a team must satisfy its commitment and at the end of the sprint the product owner must say 'decharge', else the team has failed. No team wants to publicly fail, so most of the time, at the end of the sprint, teams take shortcuts to satisfy the deadline. Those shortcuts are killing for quality! Asking for commitment is like not trusting the intrinsic motivation of the team. The correct commitment is visible during each standup. During a standup team members have to tell each other what they've done the day before. If they are working too long on a story, another team member will rebel. That is the real commitment.
  3. One of the reasons why we do scrum is that it is better to start immediately instead of doing an estimation and a feasibility study upfront, because almost always after the study is completed, the project will be executed. The estimation at the start is not reliable and the feasibility study is just a waste of time. Isn't that the same mistake we make with scrum with the grooming and ready sessions that causes a lot of overhead? The first overhead during grooming is that we give an estimation with relative precision. It is in a developer's nature to argue about the story points; is it 3, 5, 8 or maybe 1 points? And that is a waste. You should only talk about the story sizes large, medium or small. Making a more precise estimation is just a waste of time, because there are too many external factors. Second, with the grooming we do a mini feasibility study. With a team we will think about a direction of the solution, which is fine. But most of the time it takes two or three sprints before it is realized in the sprint. And with all the weekends of beer in between we've already forgot the solutions. So one smart guy says: 'yes, lets document it', but that is an inefficient way for the real problem: there is too much time between the grooming and the realization.

Scrumban: the board of kanban

Untitled

A scrumban board

The first column in a scrumban board is reserved for the backlog, where stories are ordered by their respective priority. There are several rules for the kanban backlog:

  1. It is the product owner's responsibility to fill this lane with stories, and keep it steadily supplied. The product owner must avoid creating or analyzing too many stories, because this is a waste and it corrupts with the Just-In-Time principle of scrumban. Therefore the scrumban board has a WIP-limit of 5 backlog stories.
  2. Assure the necessary level of analysis before starting development. Each story must be analyzed with a minimum effort. That should be done in the Weekly Time Box (WTB), which will be discussed later on.
  3. The backlog should be event-driven with an order point.
  4. Prioritization-on-demand. The ideal work planning process should always provide the team with best things to work on next, no more and no less.

Next to the backlog-column is the tasking-column, in which there should always be at least one story that is tasked (a minimum WIP-limit). If this isn't the case the team will task after the standup to satisfy this condition. A story is picked up from the backlog and is tasked by the team. Tip: put the tasked cards at the back of the story cards. The next columns are the realization columns. Each team is free to add, remove or change necessary columns so it suits the business. In the realization columns there should be a maximum number of stories that are worked on. If the maximum limit has not been reached, a story can be pulled from the tasking column and unfolded on the 'to implement' lane. Now the team can work on the tasks of the story. Each task that is implemented can be moved to the 'ready' lane. If all of the tasks are done for a story, the story can be moved to the next lane. When the story and tasks are ready, the cards can be moved to the right bottom of the board, so there is a new horizontal lane available for the next story.

Scrumban: the ceremonies of scrum

With scrumban we only have two types of meetings: the daily standup and the weekly timeblock. The Weeky Timeblock is a recurring meeting used for multiple purposes. It should be set up in the middle of the week. The big advantage of the weekly timeblock is that developers are distracted from their work only once a week (instead of the various of meetings with scrum).

The Weekly Timeblock contains three parts. First there is a demo of the work done. Second, there is a retrospective on the development process of the last week. Third, the team should have a preview of upcoming workitems. The team try to understand the intent of each item and provide feedback. The only size-indication a team has to make is if the story is small, medium or large. Avoid using poker cards/story points, which are too fine-grained and are to vague.

Conclusion

Scrumban is a mix of the scrum ceremonies and the kanban method. With scrumban we

  1. Introduce the weekly timeblock (WTB). The weekly timeblock should be around 4 hours and there are no more meetings
  2. Have a wider lifecycle of a story: 'from concept to cash'.
  3. Change the scrumboard to  company flows and avoid the push principle of a sprint but using a pull mechanism.

Tokutek White Paper: A Comparison of Log-Structured Merge (LSM) and Fractal Tree Indexing

What data structure does your database use? It's not something the typical database user spends much time pondering. Since data structure is destiny, what data structure your database uses is a key point to consider in your selection process.

We know CouchDB uses a modified B+ tree. We've learned a lot fascinating details over the years about the use of Log-structured merge-trees in Cassandra, HBase and LevelDB. So B+ trees and LSMs seem familiar by now.

What may not be so familiar is Tokutek's Fractal Tree Indexing technology that is supposed to be even better than B+ trees and LSMs.

As a comparison between Fractal Tree Indexing and LSMs, Bradley Kuszmaul, Chief Architect at Tokutek, has written a detailed paper, a must read for the algorithmically inclined or someone interested in database internals: A Comparison of Log-Structured Merge (LSM) and Fractal Tree Indexing.

Here's a quick intro to Fractal Tree (FT) indexes:

Categories: Architecture

How to Avoid Three Big Estimation Traps Posted

I sent a Pragmatic Manager email last week, How to Avoid Three Big Estimation Traps. If you subscribed, you’d have seen it already. (That was a not-so-subtle hint to subscribe :-)

If you’re not sure of the value of being on yet-another-email list, browse the back issues. You can see I’m consistent. Not about the day I send the Pragmatic Manager email. I can’t make myself be that consistent. I provide you some great content. I tell you where I’m speaking. I let you know where you can read my writing, and how to find more of my work. That’s it.

In any case, take a look at How to Avoid Three Big Estimation Traps. I bet you’ll like it!

Categories: Project Management

Kanban should be the default choice for DevOps teams

Xebia Blog - Wed, 08/06/2014 - 14:59

We had a successful workshop on DevOpsDays 2014. Our main point was that Kanban should be the default choice for DevOps teams. The presentation can be downloaded here.

DevOpsDays 2014 was a success

On the 19th, 20th & 21st of June 2014 the second edition of DevOpsDays Amsterdam was held in Pakhuis De Zwijger in Amsterdam. This year I was asked to teach a course there on Kanban for DevOps. At the 2013 edition I also gave a presentation about this subject and it was nice to be invited back to this great event.

With the Open Source mindset in mind I teamed up with Maarten Hoppen en Bas van Oudenaarde. Our message: Kanban should be the default choice for DevOps teams. 

The response to this workshop was very positive and because we received a lot of great feedback I thought I’d share the slide deck. The presentation assumes you are working in an environment where DevOps might work or is already being implemented. 

Main points of the presentation

DevOps is about Culture, Automation, Measurement and Sharing (CAMS). These four values require a way of working that looks past existing processes, handovers and role descriptions. 

The Kanban Method is about looking at your organization in a different way. From a point of:

  • Sustainability: by shaping demand and limiting Work in Progress
  • Service-Orientation: by creating an SLA based on past results and data
  • Survivability: create an improvement mindset in the organization to respond to rapidly changing environments

The three different ways the Kanban Method makes you look at your organization makes it an extremely powerful solution for DevOps.

If you are interested to learn more about the workshop, check out the slides here:

http://www.slideshare.net/jsonnevelt/kanban-bootcamp-devopsdays-2014

Quote of the Day

Herding Cats - Glen Alleman - Wed, 08/06/2014 - 14:38

No data hath meaning apart from their context. ~unknown

Related articles How to Forecast the Future Failure is NOT an Option!
Categories: Project Management

Seven Deadly Sins of Metrics Programs: Wrath

Wrath

Wrath

Wrath is the inordinate and uncontrolled feelings of hatred and anger.  I suspect that you conjure a picture of someone striking out with potentially catastrophic results.  When applied to measurement, wrath is the use of data in a negative or self-destructive manner (rather than an act of wrathful measurement). Very few people are moved to measure by wrath, rather they are moved by wrath to use measurement badly. Wrath causes people to act in a manner that might not be in their or in the organization’s best interest. Both scenarios are bad.  Data and the information (good or bad) derived from that data can used as a weapon in a manner that destroys the credibility of the program and the measurement practitioners.  

Anger impairs one’s ability to process information and to exert cognitive control over their behavior. An angry person may lose his/her objectivity, empathy, prudence or thoughtfulness and may cause harm to others. Actions driven by extreme anger is easily recognized by observers, but rarely by those perpetrating the behavior. This is an example of being blind with rage.  There is no room in the workplace for rage. Protect your measurement program and your career by staying in control. When confronted with scenarios that induce rage you need to learn how to step back and see the whole situation. Being mad or angry is fine if those emotions do not cloud your judgment. Teaching yourself to always see things more calmly will help your realize the truth of the harm that you are causing to yourself and others through rage. I once saw a CIO fly off the hook when are project shared it’s measurement dashboard, the project reporting that they were behind schedule, defects were above projections and the number of potential risks were rising. The uncontrolled rant was awe inspiring however the CIO lost the support of his senior leaders and within a month he was gone. Control puts you in a position to react in a more rational manner.

Measurement data and the information derived from that data deliver the ability to understand why things happen: why a project is late, why a project costs what it does or even why a specific level of quality was achieved.  Measurement is a tool to take action to improve how work is done.  What it should not be is a weapon of indiscriminate destruction. Acting in a rage changes all of that. When you strike out in an uncontrolled manner you have transformed that data into a weapon with very little guidance. Think of the difference between the indiscriminate nature of a land mine and the precision of phasers of the Star Ship Enterprise. Wrath turns a potentially valuable tool into something far less reliable. For example, a purposeful misrepresentation of the meaning of data can lead to team or organization making wrong decisions. Other examples include errors of omissions (leaving out salient facts) or inclusion (including irrelevant data that changes the conclusions drawn from the data).  Whether omission or inclusion, poor use of data erodes the value of the measurement program though politicization or placing doubt about the value of measurement into people’s minds. Remember that all analysis requires interpretation, however the interpretations are generally based on an assumption that people will act logically and consistently. That includes your behavior. Analysis based on an obviously false assumptions just to make a point does no one any good in the long run.  For example, assuming productivity is constant across all sized of projects so that you can show that a project under-performed to get back at someone will destroy your credibility even if you win the argument. Be true to the data or be the point of a failure in trust.  

Do not confuse passion and rage; they are not the same. You must have passion to be effective but what you can’t do, is to lose control of your emotions to the point that you stop thinking before you act. The deadly sin of wrath is a sin that reflection of bad behavior, if you let wrath affect your behavior you will begin a spiral that ends with a failure of trust.


Categories: Process Management

PMI Professional in Business Analysis

Software Requirements Blog - Seilevel.com - Tue, 08/05/2014 - 17:00
PMI is offering a new certification, and this one is aimed at business analysts. Called the PMI Professional in Business Analysis (PMI-PBA), PMI is recognizing the growth of business analysts in the industry, as well as the role that BAs play. Intrigued, I decided to look more into it, as I’m still a few hours […]
Categories: Requirements

Sponsored Post: Apple, Gawker, FoundationDB, Monitis, Cie Games, BattleCry, Surge, Cloudant, CopperEgg, Logentries, Couchbase, MongoDB, BlueStripe, AiScaler, Aerospike, AppDynamics, ManageEngine, Site24x7

Who's Hiring?
  • Apple has multiple openings. Changing the world is all in a day's work at Apple. Imagine what you could do here. 
    • Software Developer in Test. The iOS Systems team is looking for a Quality Assurance engineer. In this role you will be expected to work hand-in-hand with the software engineering team to find and diagnose software defects. The ideal candidate will also seek out ways to further automate all aspects of our existing process. This is a highly technical role and requires in-depth knowledge of both white-box and black-box testing methodologies. Please apply here
    • Senior Software Engineer -iOS Systems. Do you love building highly scalable, distributed web applications? Does the idea of a fast-paced environment make your heart leap? Do you want your technical abilities to be challenged every day, and for your work to make a difference in the lives of millions of people? If so, the iOS Systems Carrier Services team is looking for a talented software engineer who is not afraid to share knowledge, think outside the box, and question assumptions. Please apply here.
    • Software Engineering Manager, IS&T WWDR Dev Systems. The WWDR development team is seeking a hands-on engineering manager with a passion for building large-scale, high-performance applications. The successful candidate will be collaborating with Worldwide Developer Relations (WWDR) and various engineering teams throughout Apple. You will lead a team of talented engineers to define and build large-scale web services and applications. Please apply here.
    • C++ Senior Developer and Architect- Maps. The Maps Team is looking for a senior developer and architect to support and grow some of the core backend services that support Apple Map's Front End Services. Ideal candidate would have experience with system architecture, as well as the design, implementation, and testing of individual components but also be comfortable with multiple scripting languages. Please apply here.

  • Systems & Networking Lead at Gawker. We are looking for someone to take the initiative on the lowest layers of the Kinja platform. All the way down to power and up through hardware, networking, load-balancing, provisioning and base-configuration. The goal for this quarter is a roughly 30% capacity expansion, and the goal for next quarter will be a rolling CentOS7 upgrade as well as to planning/quoting/pitching our 2015 footprint and budget. For the full job spec and to apply, click here: http://grnh.se/t8rfbw

  • Cie Games, small indie developer and publisher in LA, is looking for rock star Senior Game Java programmers to join our team! We need devs with extensive experience building scalable server-side code for games or commercial-quality applications that are rich in functionality. We offer competitive comp, great benefits, interesting projects, and exceptional growth opportunities. Check us out at http://www.ciegames.com/careers.

  • BattleCry, the newest ZeniMax studio in Austin, is seeking a qualified Front End Web Engineer to help create and maintain our web presence for AAA online games. This includes the game accounts web site, enhancing the studio website, our web and mobile- based storefront, and front end for support tools. http://jobs.zenimax.com/requisitions/view/540

  • FoundationDB is seeking outstanding developers to join our growing team and help us build the next generation of transactional database technology. You will work with a team of exceptional engineers with backgrounds from top CS programs and successful startups. We don’t just write software. We build our own simulations, test tools, and even languages to write better software. We are well-funded, offer competitive salaries and option grants. Interested? You can learn more here.

  • UI EngineerAppDynamics, founded in 2008 and lead by proven innovators, is looking for a passionate UI Engineer to design, architect, and develop our their user interface using the latest web and mobile technologies. Make the impossible possible and the hard easy. Apply here.

  • Software Engineer - Infrastructure & Big DataAppDynamics, leader in next generation solutions for managing modern, distributed, and extremely complex applications residing in both the cloud and the data center, is looking for a Software Engineers (All-Levels) to design and develop scalable software written in Java and MySQL for backend component of software that manages application architectures. Apply here.
Fun and Informative Events
  • OmniTI has a reputation for scalable web applications and architectures, but we still lean on our friends and peers to see how things can be done better. Surge started as the brainchild of our employees wanting to bring the best and brightest in Web Operations to our own backyard. Now in its fifth year, Surge has become the conference on scalability and performance. Early Bird rate in effect until 7/24!
Cool Products and Services
  • Couchbase, MongoDB and DataStax: Compared. Find out which database delivers great read/write latency while scaling well with both read-intensive and balanced workloads. Get the initial results here: http://info.couchbase.com/2014-Benchmark-Showdown-Results-LP.html.

  • Now track your log activities with Log Monitor and be on the safe side! Monitor any type of log file and proactively define potential issues that could hurt your business' performance. Detect your log changes for: Error messages, Server connection failures, DNS errors, Potential malicious activity, and much more. Improve your systems and behaviour with Log Monitor.

  • The NoSQL "Family Tree" from Cloudant explains the NoSQL product landscape using an infographic. The highlights: NoSQL arose from "Big Data" (before it was called "Big Data"); NoSQL is not "One Size Fits All"; Vendor-driven versus Community-driven NoSQL.  Create a free Cloudant account and start the NoSQL goodness

  • Finally, log management and analytics can be easy, accessible across your team, and provide deep insights into data that matters across the business - from development, to operations, to business analytics. Create your free Logentries account here.

  • CopperEgg. Simple, Affordable Cloud Monitoring. CopperEgg gives you instant visibility into all of your cloud-hosted servers and applications. Cloud monitoring has never been so easy: lightweight, elastic monitoring; root cause analysis; data visualization; smart alerts. Get Started Now.

  • Whitepaper Clarifies ACID Support in Aerospike. In our latest whitepaper, author and Aerospike VP of Engineering & Operations, Srini Srinivasan, defines ACID support in Aerospike, and explains how Aerospike maintains high consistency by using techniques to reduce the possibility of partitions.  Read the whitepaper: http://www.aerospike.com/docs/architecture/assets/AerospikeACIDSupport.pdf.

  • BlueStripe FactFinder Express is the ultimate tool for server monitoring and solving performance problems. Monitor URL response times and see if the problem is the application, a back-end call, a disk, or OS resources.

  • aiScaler, aiProtect, aiMobile Application Delivery Controller with integrated Dynamic Site Acceleration, Denial of Service Protection and Mobile Content Management. Cloud deployable. Free instant trial, no sign-up required.  http://aiscaler.com/

  • ManageEngine Applications Manager : Monitor physical, virtual and Cloud Applications.

  • www.site24x7.com : Monitor End User Experience from a global monitoring network.

If any of these items interest you there's a full description of each sponsor below. Please click to read more...

Categories: Architecture

Material design in the 2014 Google I/O app

Android Developers Blog - Tue, 08/05/2014 - 16:39
figure { margin: 0 0 20px 0; } figcaption { font-style: italic; opacity: 0.7; } figure img { padding: 0 !important; } blockquote { font-style: italic; }

By Roman Nurik, lead designer for the Google I/O Android App

Every year for Google I/O, we publish an Android app for the conference that serves two purposes. First, it serves as a companion for conference attendees and those tuning in from home, with a personalized schedule, a browsing interface for talks, and more. Second, and arguably more importantly, it serves as a reference demo for Android design and development best practices.

Last week, we announced that the Google I/O 2014 app source code is now available, so you can go check out how we implemented some of the features and design details you got to play with during the conference. In this post, I’ll share a glimpse into some of our design thinking for this year’s app.

On the design front, this year’s I/O app uses the new material design approach and features of the Android L Developer Preview to present content in a rational, consistent, adaptive and beautiful way. Let’s take a look at some of the design decisions and outcomes that informed the design of the app. Surfaces and shadows

In material design, surfaces and shadows play an important role in conveying the structure of your app. The material design spec outlines a set of layout principles that helps guide decisions like when and where shadows should appear. As an example, here are some of the iterations we went through for the schedule screen:

First iteration Second iteration Third iteration

The first iteration was problematic for a number of reasons. First, the single shadow below the app bar conveyed that there were two “sheets” of paper: one for the app bar and another for the tabs and screen contents. The bottom sheet was too complex: the “ink” that represents the contents of a sheet should be pretty simple; here ink was doing too much work, and the result was visual noise. An alternative could be to make the tabs a third sheet, sitting between the app bar and content, but too much layering can also be distracting.

The second and third iterations were stronger, creating a clear separation between chrome and content, and letting the ink focus on painting text, icons, and accent strips.

Another area where the concept of “surfaces” played a role was in our details page. In our first release, as you scroll the details screen, the top banner fades from the session image to the session color, and the photo scrolls at half the speed beneath the session title, producing a parallax effect. Our concern was that this design bent the physics of material design too far. It’s as if the text was sliding along a piece of paper whose transparency changed throughout the animation.

A better approach, which we introduced in the app update on June 25th, was to introduce a new, shorter surface on which the title text was printed. This surface has a consistent color and opacity. Before scrolling, it’s adjacent to the sheet containing the body text, forming a seam. As you scroll, this surface (and the floating action button attached to it) rises above the body text sheet, allowing the body text to scroll beneath it.

This aligns much better with the physics in the world of material design, and the end result is a more coherent visual, interaction and motion story for users. (See the code: Fragment, Layout XML)

Color

A key principle of material design is also that interfaces should be “bold, graphic, intentional” and that the foundational elements of print-based design should guide visual treatments. Let’s take a look at two such elements: color and margins.

In material design, UI element color palettes generally consist of one primary and one accent color. Large color fields (like the app bar background) take on the main 500 shade of the primary color, while smaller areas like the status bar use a darker shade, e.g. 700.

The accent color is used more subtly throughout the app, to call attention to key elements. The resulting juxtaposition of a tamer primary color and a brighter accent, gives apps a bold, colorful look without overwhelming the app’s actual content.

In the I/O app, we chose two accents, used in various situations. Most accents were Pink 500, while the more conservative Light Blue 500 was a better fit for the Add to Schedule button, which was often adjacent to session colors. (See the code: XML color definitions, Theme XML)

And speaking of session colors, we color each session’s detail screen based on the session’s primary topic. We used the base material design color palette with minor tweaks to ensure consistent brightness and optimal contrast with the floating action button and session images.

Below is an excerpt from our final session color palette exploration file.

Session colors, with floating action button juxtaposed to evaluate contrast Desaturated session colors, to evaluate brightness consistency across the palette Margins

Another important “traditional print design” element that we thought about was margins, and more specifically keylines. While we’d already been accustomed to using a 4dp grid for vertical sizing (buttons and simple list items were 48dp, the standard action bar was 56dp, etc.), guidance on keylines was new in material design. Particularly, aligning titles and other textual items to keyline 2 (72dp on phones and 80dp on tablets) immediately instilled a clean, print-like rhythm to our screens, and allowed for very fast scanning of information on a screen. Gestalt principles, for the win!

Grids

Another key principle in material design is “one adaptive design”:

A single underlying design system organizes interactions and space. Each device reflects a different view of the same underlying system. Each view is tailored to the size and interaction appropriate for that device. Colors, iconography, hierarchy, and spatial relationships remain constant.

Now, many of the screens in the I/O app represent collections of sessions. For presenting collections, material design offers a number of containers: cards, lists, and grids. We originally thought to use cards to represent session items, but since we’re mostly showing homogenous content, we deemed cards inappropriate for our use case. The shadows and rounded edges of the cards would add too much visual clutter, and wouldn’t aid in visually grouping content. An adaptive grid was a better choice here; we could vary the number of columns on screen size (see the code), and we were free to integrate text and images in places where we needed to conserve space.

Delightful details

Two of the little details we spent a lot of time perfecting in the app, especially with the L Developer Preview, were touch ripples and the Add to Schedule floating action button.

We used both the clipped and unclipped ripple styles throughout the app, and made sure to customize the ripple color to ensure the ripples were visible (but still subtle) regardless of the background. (See the code: Light ripples, Dark ripples)

But one of our favorite details in the app is the floating action button that toggles whether a session shows up in your personalized schedule or not:

We used a number of new API methods in the L preview (along with a fallback implementation) to ensure this felt right:

  1. View.setOutline and setClipToOutline for circle-clipping and dynamic shadow rendering.
  2. android:stateListAnimator to lift the button toward your finger on press (increase the drop shadow)
  3. RippleDrawable for ink touch feedback on press
  4. ViewAnimationUtils.createCircularReveal for the blue/white background state reveal
  5. AnimatedStateListDrawable to define the frame animations for changes to icon states (from checked to unchecked)

The end result is a delightful and whimsical UI element that we’re really proud of, and hope that you can draw inspiration from or simply drop into your own apps.

What’s next?

And speaking of dropping code into your own apps, remember that all the source behind the app, including L Developer Preview features and fallback code paths, is now available, so go check it out to see how we implemented these designs.

We hope this post has given you some ideas for how you can use material design to build beautiful Android apps that make the most of the platform. Stay tuned for more posts related to this year’s I/O app open source release over the coming weeks to get even more great ideas for ways to deliver the best experience to your users.


Join the discussion on
+Google Design


Categories: Programming

Quote of the Day

Herding Cats - Glen Alleman - Tue, 08/05/2014 - 16:34

A point of view can be a dangerous luxury when substituted for insight and understanding.
~ Marshall McLuhan

Categories: Project Management