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

Code Golf

Phil Trelford's Array - Sat, 08/02/2014 - 19:22

Last month Grant Crofton popped down from Leeds to the F#unctional Londoners meetup at Skills Matter to run a fun hands on code golf session. The idea of code golf is to implement a specific algorithm in the fewest possible characters. This is not the kind of thing you should be doing in enterprise code, but it is fun, and an interesting way of exploring features in a programming language.

On the night we attempted condensed versions of FizzBuzz and 99 bottles of beer, with Ross and I winning the first challenge and Simon & Adrian the second.

FizzBuzz Score99 Bottles Score

Thanks again to Grant for a really fun session.

F# FizzBuzz

A while back I strived to squeeze an F# implementation of FizzBuzz into a tweet, and with white space removed it weighs in at 104 characters (excluding line breaks):

for n=1 to 100 do 
 printfn"%s"
  (match n%3,n%5 with 0,0->"FizzBuzz"|0,_->"Fizz"|_,0->"Buzz"|_,_->string n)

The implementation, although quite clear, requires a fair number of characters for the pattern matching portion.

After some head scratching we came up with the idea of using a lookup to select the string to display:

N %3 N % 5 Index Output 0 0 0 N >0 0 1 “Fizz” 0 >0 2 “Buzz” >0 >0 3 “FizzBuzz”

This took the implementation down to 89 characters (without line breaks):

for i=1 to 100 do
 printfn"%s"["FizzBuzz";"Buzz";"Fizz";string i].[sign(i%5)*2+sign(i%3)]

Another trick is to abuse the sign function, to get 1 if the result of the modulus is above 0 and 0 otherwise.

The lookup trick can be used in other languages, and here’s a few examples, just for fun.

VB.Net FizzBuzz

VB.Net has a reputation for being a little verbose, but using the lookup trick it was possible to it get down to 96 characters (excluding line breaks):

For i=1 To 100:
Console.WriteLine({i,"Fizz","Buzz","FizzBuzz"}(-(i Mod 3=0)-(i Mod 5=0)*2))
:Next

In VB.Net true values translate to –1 and false to 0. This allowed me to simply negate the result of i % N = 0 to compute an index.

Python FizzBuzz

Using a similar trick in Python, where true translates to 1 and 0 to false, I was able to get to a very respectable 79 characters (excluding line breaks):

for x in range(1,101):
 print([x,"Fizz","Buzz","FizzBuzz"][(x%3==0)+2*(x%5==0)])

Python’s simple print function also helped to keep the character count down.

Amanda FizzBuzz

Amanda is a variant of David Turner’s quintessential functional programming language Miranda. Amanda runs on Windows, and is used for teaching FP at some universities.

Using a list comprehension it was possible to squeeze in to a mere 67 characters:

[["FizzBuzz","Buzz","Fizz",itoa x]!(min[1,x%3]+min[1,x%5]*2)|x<-[1..100]]

Note: this is cheating a little as we are not explicitly writing to the console.

APL FizzBuzz

APL is a very mature language, dating back to the 1960s, and is still used commercially today. It also wins hands down in code golf with just 54 characters:

⍪{'FizzBuzz' 'Buzz' 'Fizz'⍵[1+(2×1⌊5|⍵)+1⌊3|⍵]}¨⍳100

APL is particularly strong at matrix processing and provides single character representations for common operations:

Notation Name MeaningB Index generator Creates a list from 1 to B ¨ Each for each loop ⍪ Table Produces a one column matrix ⌊B Floor Greatest integer less than or equal to B

Try APL in your browser now.

Challenge

Can you beat the APL implementation of FizzBuzz?

Have fun!

Categories: Programming

Seven Deadly Sins of Metrics Programs

3216110254_15d4a00bf2_b

In Christianity, the seven deadly sins are the root of all other sins. This concept has been used as an analogy for the ills or risks for many professions.  The analogy fits as well for software metrics; focusing attention on the behaviors that could sap your program’s integrity, effectiveness and lifespan. Here we will look at the deadly sins from the point of view of a person or group that is creating or managing a metrics program. As with many things in life, forewarned is forearmed, and knowledge is a step towards avoidance.

Here are the seven deadly sins of metrics programs:

  • Pride – Believing that a single number/metric is more important than any other factor.
  • Envy – Instituting measures that facilitate the insatiable desire for another team’s people, tools or applications.
  • Wrath – Using measures to create friction between groups or teams.
  • Sloth – Unwillingness to act on or care about the measures you create.
  • Greed – Allowing metrics to be used as a tool to game the system for gain.
  • Gluttony – Application of an excess of metrics.
  • Lust – Pursuit of the number rather than the business goal.

All of the deadly sins have an impact on the value a metrics program can deliver.  Whether anyone sin is more detrimental than another is often a reflection of where a metrics program is in it’s life cycle. For instance, pride, the belief that one number is more important than all other factors, is more detrimental than sloth or a lack of motivation as a program begins whereas sloth becomes more of an issue as a program matures.  These are two very different issues with two very different impacts, however neither should be sneezed at if you value the long-term health of a metrics program. Pride can lead to overestimating your capabilities and sloth can lead to not using those you have in the end self-knowledge is the greatest antidote.

Over the next few days we will visit the seven deadly sins of metrics!


Categories: Process Management

Can Enterprise Agile Be Bottom Up?

Herding Cats - Glen Alleman - Fri, 08/01/2014 - 20:48

Much of the objection to SAFe comes from its seemingly Top Down paradigm. Many agile voices object that this approach is not agile, in the way they define agile - individual teams making their own decisions about what to do with their customer.

The domain of this bottom up approach is usually not well defined, other than the classic eXtreme Programming or the Agile Spectrum of  where Co-Hacking is on the left, where the developers live by the pure agile manifesto. 

But what happens when agile is applied to an enterprise development effort. One where the business needs define the capabilities that are not emergent, but rather they are needed to fulfill the business strategy or the mission of the organization. Then another paradigm emerges. One where higher order questions, frameworks, framing assumptions, governance, and other externalities trump the needs of the individual team.

Here's one approach that has served us well over time. 

Critical Success Factors for ERP from Glen Alleman   So when we hear about critisms of SAFe like:
  • The structure and teaching of SAFe is relentlessly top down. All the important stuff is figured out up in Portfolio. All the features are figured out up in Program. Now you guys Build and Test that.

The  statement is a bit off, since it's the Capabilities that are defined by the business. These capabilities are then turned into requirements, which may in fact emerge, which themselves are turned into working software. Starting with the capabilities, an enterprise software development effort means re-looking at the agile manifesto statements.

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    • It certaintly is the highest priority to satisfy the customer with valuable software.
    • The delivery in the enterprise needed to be planned at the absorption rate and business rhythm. 
    • The units of measure of value need to be connected to the business strategy. This is usually to role  of Balanced Scorecard, which defines the value in the 4 perspectives of the business. 
      • Financial
      • Customer
      • Internal business processes
      • Learning and Growth
      • Here's how to develop your BSC for enterprise software development.
    • Releasing software in the enterprise means integrating with the business processes, customer processes, product release process - all defined by the rhythm of how the business works
    • Imagine updating the point of sale terminals across 10,000 users on a daily basis, adding new features, changing possibly for the better how they work.
    • The training, Tier 1 support, transaction formatting, and other enterprise actiities woudl alos have to change.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

    • This is one of those untested statements.
    • Imagine changing how ICD-10 claims are processed late in the development cycle.
    • Other enterprise systems are based on ICD-10 formats, now they're changing as we approach "go live." 
    • We need look no further than the ACA roll out to see how nonsensical this is.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    • For the enterprise, the business rhythm defines the frequency of software release. 
    • For example, the flight navigation systems for an aircraft have many other processes beyond just writing code. 
    • Full Information Assurance, DO-178 validation, Digital Flight Bag integration, PCI
    • For health care SP-600 for HIPPA verification and validation.
    • Or for the IT Enterprise ISACA.
    • Externalities drive business rhythm. Having the developers decide this rhythm ignores these externalities. If there are no externalities, then the project is likely perfect for the agile manifesto.
  • Business people and developers must work together daily throughout the project.

    • This works when the business people don't have day jobs.
    • If they have day jobs, some proxy of the needed capabilities, and requirements is needed.
    • This is the role of documentation and models. Both developed concurrently with developers and business people.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    • Can't go wrong here.
    • Remember thought, trust but verify.
    • The value at risk needs to be considered. What happens if what the developers say turns out not to be the case. How much are you willing to risk that the trust was misplaced?
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    • Back to the availability issue. 
    • Geography is another issue. Many teams are distributed.
    • Face to Face needs a proxy.
  • Working software is the primary measure of progress.

    • Correct, this is basis of Earned Value Management's Physical Percent Complete.
    • Working needs a definition. Measures of Effectiveness, Measures of Performance, Key Performance Parameters, Technical Performance Measures are all mechanisms to assess the workingness of the software in the enterprise domain.
  • Agile processes promote sustainable development. 

    • All work processes should be sustainable, nit just agile.
    • Knowing the capacity for work is the starting point.
    • This means not only knowing the capacity, but planning the work around this capacity with the needed margin to provide for sustainability.
  • The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    • Yes, good business and engineering practice.
    • Requires capacity planning
    • Cost, Schedule, and Technical margin.
    • Measures of performance to make steering adjustment and needs a control system to connect the dots between the desired outcome, and actual performance, and the corrective actions needed to sustain this needed performance.
  • Continuous attention to technical excellence and good design enhances agility.

    • This is a platitude that is used in all engineering domains.
    • rarely if ever are product build with low technical excellence and good design practices.
    • Exactly how this enhances agility is untested outside of anecdotes.
    • But certainly changeability in response to external factors is measurable as robustness of the design.
  • Simplicity - the art of maximizing the amount of work not done - is essential.

    • Another platitude, without any actionable suggestions.
    • But what are the units of measure of simplicity.
    • Everyone should read Synthesis of Form, Christopher Alexander.
    • Then the practice for enterprise projects, The Art of Systems Architecting, 2nd Edition, Mark W. Maier and Eberhardt Rechtin.
    • And followed by Systems Engineering: Coping with Complexity, Richard Stevens, et al.
    • These three books address the platitude and replace it with actionable steps to maximize value produced with minimal work.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

    • In the enterprise domain this is a non-starter.
    • Architecture is the glue to holds the systems integration together.
    • Emerging architectures means, all the other systems in the enterprise will be constantly changing as the architecture of the system under development changes.
    • Those self-organizing teams may or may not have the skills, experience, and even ability to be  systems architects.
    • Read the systems engineering books above. Join www.incose.org to learn how complex enterprise systems are defined, developed, deployed, and maintained.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    • This is standard good engineering practice, not unique to agile.

So What Does All This Mean?

Without a domain, hard to assess the applicability and appropriateness of much of anything.

What this really means of Scaled Agile Framework is the place to start for the enterprise.

Related articles Agile Requires Discipline, In Fact Successful Projects Require Discipline Agile and the Federal Government The Agile Architecture Mind Map Capabilities Based Planning and Development Agile in the enterprise: To succeed, avoid the fundamentalists How To Create Confusion About Root Causes Agile Paradigm The Myth of Incremental Development An Agile Estimating Story Agile as a Systems Engineering Paradigm
Categories: Project Management

Stuff The Internet Says On Scalability For August 1st, 2014

Hey, it's HighScalability time:


From Systems Performance: Enterprise and the Cloud.
  • Quotable Quotes:
    • @shanselman: Wife: "How was your day?" Me: "I'm using Grunt to automate NuGet creation for AngularJS." Wife: "But will that scale?" Me: "Well played."
    • John Hagel: winners in the concentrating parts of the economy are increasingly determined by the ability to connect with, and build strong relationships with, the participants who are operating in fragmenting parts of the economy.
    • Jack Clark: This means that although Amazon still grew at a respectable rate, its actual revenues were clipped by the heightened competition. This is what happens when you sell goods with deflationary pricing, it seems.

  • Taxi app Hailo on Scaling micro-services Architecture on AWS: Micro-services + Containers + Scheduling on AWS will be a dominant architecture pattern in the next few years.

  • Netflix. Revisiting 1 Million Writes per second. How will Cassandra perform on AWS's new instance types? There's no big reveal so you'll have to decide for yourself. Good discussion on reddit and Hacker News.

  • TrueTime in Google's Spanner was one of its most buzzworthy innovations. Who doesn't like atomic clocks as a way to time-stamp transactions anywhere in the world? What if you don't have spare atomic clocks? Hybrid Logical Clocks: HLC captures the causality relationship like LC, and enables easy identification of consistent snapshots in distributed systems. Dually, HLC can be used in lieu of PT clocks since it maintains its logical clock to be always close to the PT clock.

  • Vertical integration for the win. Apple is building out their own CDN with many terabits of capacity. Capable of handling traffic bursts from software downloads. Or maybe something else? More from Dan Rayburn in Apple’s CDN Now Live: Has Paid Deals With ISPs, Massive Capacity In Place

  • Clouds make a lot of money on their network pricing. Chris Swan explores this marketing magic in Cloud Price Wars – What about the network?: there haven’t been any major shifts in network pricing.

  • Scaling with Microservices and Vertical Decomposition: The architecture of otto.de is based on the concept of vertical decomposition: the whole system is vertically split into several loosely coupled applications. Every “vertical” is responsible for a single business domain such as “Order”, “Search & Navigation”, “Product”, etc. It has its own presentation layer, persistence layer and a separate database. From the development perspective, every vertical is implemented by exactly one team and no code is shared between the different systems.

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

Playing around with Yo

Xebia Blog - Fri, 08/01/2014 - 13:09

Yo has been quite a bit in the news lately. Mainly because it got a lot of investment, which surprised and shocked some people because it all seems too simple. Yo only allows you to send a Yo notification to other users. However, it has a lot of potential to become big while staying that simple.

Screenshot 2014-08-01 14.23.48

After reading Why A Stupid App Like Yo May Have Billion-Dollar Platform Potential a few days ago I felt it was time to play around a bit with Yo and it's API.

I came up with 3 very simple use cases that should be simple to solve with Yo:

  • Get a Yo when it's time to have lunch when I'm at work
  • Get a Yo when I forgot to check out from my parking App
  • Get a Yo when a new blog post is published here on the Xebia Blog

Time to register a couple of Yo developer usernames. The Yo API is, just like Yo itself, very simple. You register a username from which you want to receive notifications at http://yoapi.justyo.co after which you'll receive an API token for that username. Once you have that, people can subscribe to that username with the Yo app. Then you can send a Yo to either all subscribers or to a single subscribe with a simple POST request and the token. All this is explained at https://medium.com/@YoAppStatus/e7f2f0ec5c3c in more detail.

Let's start with our lunch notifications. I created the TIME2LUNCH username for this. I want my notifications at 12:00pm, since that's the time I go to lunch. So all I need is some service that sends the POST request every day at 12:00pm (for now I don't care about getting one in the weekend as well and I only care about my own time zone, Central European Time). Using NodeJS, it's just a single line of code to do such a request:

require('request')
  .post('http://api.justyo.co/yoall/', 
    {
      form: {api_token: 'my_secret_api_token'}
    }
  );

Now we need to have a scheduler that executes it every day at 12:00pm. Luckily Heroku has a scheduler that can do exactly that:

Screenshot 2014-07-31 17.43.51

So after deploying our javascript file with a single line of code and creating our scheduled job we will receive our daily Yo from TIME2LUNCH. Not bad for a first attempt.

Usually my co-workers will remind me when it's time to go to lunch so let's do something that's actually a bit less useless.

To park my car near the office I always use the Parkmobile service. At the end of the day I have to check out to avoid paying too much. Unfortunately it's an easy thing to forget. Parkmobile knows this and can send sms alerts at a specific time or after parking a certain amount of hours. Unfortunately they charge € 0.25 per sms. They also send e-mails, but they're easier to miss. It would be nice to get a Yo instead, for free of course.

What we need is to send the Yo POST request each time we receive the Parkmobile e-mails. Sounds like we might be able to use IFTTT (if this then that) to accomplish this. When browsing for channels and recipes on IFTTT I saw that they already support Yo as a channel. I thought I was gonna be done fast. Unfortunately it's only possible to use Yo as a trigger (if Yo then that) and not as an action (if this then Yo). So we need another solution here. I couldn't find a way to send a cURL request directly from IFTTT, but when Googling for a solution I found a webhook project: https://github.com/captn3m0/ifttt-webhook. The ifttt-webhook works by acting as a WordPress site, which is something that can act as an action of IFTTT. It then allows us to send a POST request to a specific URL. Not exactly the POST requests that are accepted by the Yo API though. But we already made some NodeJS code to send a Yo request so I'm sure we can add some code to accept a request from the ifttt-webhook and then pass it on to something that Yo does understand.

If we follow the instructions on the Github page and set our username to our Yo username and use our API token as password, then the webhook will send a POST request with a JSON body that looks something like this:

{ user: 'MYUSERNAME', pass: 'ab1234-1234-abcd-1234-abcd1234abcd', title: '' }

We can handle that in NodeJS like this:

var express = require('express');
var bodyParser = require('body-parser')
var app = express();
var request = require('request');

app.use(bodyParser.json());
app.post('/api/yo', function (req, res) {
  var user = req.body.user;
  var apiToken = req.body.pass;
  request.post('http://api.justyo.co/yo/',
    {
      form: {
        api_token: apiToken,
        username: user
      }
    });
});

var port = Number(process.env.PORT || 5000);
app.listen(port, function() {
  console.log('Listening on ' + port);
});

This is just a simple express web server that listens for POST calls on /api/yo and then uses the user and pass fields from the body to send a POST request to the Yo API.

This is deployed at http://youser.herokuapp.com/ so everyone can use it as a IFTTT to Yo action.

We can now create our IFTTT recipe. Creating the this step is easy. I receive the e-mails from Parkmobile in my Gmail and their e-mail address is norepy@parkmobile.com. So the rule becomes to trigger each time when I receive an email from them. Then in the that step I activate the WordPress channel with the Yo username and api token and in the body I set the http://youser.herokuapp.com/api/yo URL.

Here is the recipe:

Screenshot 2014-07-31 18.32.12

The last use case I had is to send a Yo each time a new blog post was posted on this blog. For that I registered the XEBIABLOG username (so make sure to subscribe to that in your Yo app if you want to get Yo'd as well for each new blog post).

Since this blog has an RSS feed, I figured I could poll that once in a while to check for new posts. We also already used the Heroku scheduler, so we might as well use that again. I found a little node library called feed-read that makes reading RSS feeds easy. So here is our little app that runs every hour:

var feed = require("feed-read");
var request = require('request');
var ONE_HOUR = 60 * 60 * 1000;

feed("http://blog.xebia.com/feed/", function(err, articles) {
  if (err) throw err;

  var lastArticle = articles[0];
  if ((new Date() - lastArticle.published) < ONE_HOUR) {
    console.log('Sending Yo for ' + lastArticle.title);
    request.post('http://api.justyo.co/yoall/',
      {
        form: {
          api_token: 'my_secret_token'
        }
      });
  }
});

We now have completed our 3 little use cases. Not the most useful things but nice non nonetheless. When looking back on them, we can imagine a couple of improvements. For example for the TIME2LUNCH it would be possible to make a little service where people could register and set their timezone at which they want to receive their notification. We could create a little database that store Yo usernames and the zone. But at this moment it's not possible to verify that USERX is really USERX. Yo doesn't support third party authentication like Facebook and Twitter have with OAuth. Perhaps that's something they will add in the future to make platform more useable for user specific notifications.

13 Business Models for Book Authors

NOOP.NL - Jurgen Appelo - Fri, 08/01/2014 - 11:03
Business Models for Book Authors

It’s such a great time to write books!

The publishing world is transforming rapidly and smart authors–with a sense of business–will thrive on opportunities that didn’t exist until a few years ago.

It appears that almost one-third of all e-books sold on Amazon are published by indie authors. This is great news for everyone who loves freedom and independence (including yours truly). On the other hand, income for book writers seems to be declining steadily. This will only get worse now that Amazon has started offering subscriptions to read unlimited numbers of e-books, thereby moving in the same direction as Netflix (for movies) and Spotify (for music), further reducing the income for authors along the way.

The post 13 Business Models for Book Authors appeared first on NOOP.NL.

Categories: Project Management

Learn How UX Design can Make Your App More Successful

Android Developers Blog - Fri, 08/01/2014 - 02:39

By Nazmul Idris, a Developer Advocate at Google who's passionate about Android and UX design

As a mobile developer, how do you create 5-star apps that your users will not just download, but love to use every single day? How do you get your app noticed, and how do you drive engagement? One way is to focus on excellence in design — from visual and interaction design to user research, in other words: UX design.

If you’re new to the world of UX design but want to embrace it to improve your apps, we've created a new online course just for you. The UX Design for Mobile Developers course teaches you how to put your designer hat on, in addition to your developer hat, as you think about your apps' ideal user and how to meet their needs.

The course is divided into a series of lessons, each of which gives you practical takeaways that you can apply immediately to start seeing the benefits of good UX design.

Without jargon or buzzwords, the course teaches you where you should focus your attention, to bring in new users, keep existing users engaged, and increase your app's ratings. You'll learn how to optimize your app, rather than optimizing login/signup forms, and how to use low-resolution wireframing.

After you take the course, you'll "level up" from being an excellent developer to becoming an excellent design-minded developer.

Check out the video below to get a taste of what the course is like, and click through this short deck for an overview of the learning plan.

The full course materials — all the videos, quizzes, and forums — are available for free for all students by selecting “View Courseware”. Personalized ongoing feedback and guidance from Coaches is also available to anyone who chooses to enroll in Udacity’s guided program.

If that’s not enough, for even more about UX design from a developer's perspective, check out our YouTube UXD series, on the AndroidDevelopers channel: http://bit.ly/uxdplaylist.


Android Developers
at Udacity

Join the discussion on
+Android Developers


Categories: Programming

Agile 2014: My Retrospective

photo

The Agile 2014 Conference is much like a symphony with many individual movements that form a whole, like the Agile movement in general. 4 of the 5 days included 15 planned tracks with at least 4 presentations per track (Friday has a much smaller number of presentations). The variety of presentations and topics reflected the range of related, but different movements classified as Agile. Topics ranged from the social sciences of psychology and sociology targeted at coaching teams and organizational change to highly technically topics such as pair programming and DevOps.  The conference attracted 3,000+ attendees and speakers. For anyone interested in Agile this is conference that not allows but almost insists on an Agile immersion experience.

Several attendees that have attended in years past suggested that this year’s attendees reflect a subtle shift. There were more decision-makers than developers/practitioners in attendance. The theme of scaled Agile was also more prevalent than in past years.

Many of the early Agile thinkers were in attendance and involved not only in presenting, but shaping the conference. None of the early thinkers have lost their particular fire. For example, one speaker from this cohort publicly lamented that sponsors were monetizing the conference. Ken Schwaber even suggested turning the branded lanyards over to hide the branding. From my perspective, picking on the vendors is an easy target that could have negative consequences. The vibrant vendor community present was a positive and provided the sponsorship needed to hold great special events that made the conference more than just a fire hose of information. Agile 2014 was also a social experience.

If continual presentations and interactive workshops are not to your liking, there were plenty of less structured events. The conference had constant hallways talks, lean coffees every morning, Open Jams, coaching clinics and space provided for one-on-one conversations. There was no shortage of ideas, nor any shortage of space to discuss those ideas outside of the formal agenda.

This conference is large enough to hit some of your important topics one day and then to explore topics outside of your comfort zone the next and then have time to switch back and forth on the third, fourth or fifth days. I overhead folks discussing an interesting strategy; spending a day attending sessions that were exactly opposite of those you would typically attend to make sure you were exposed to new ideas.

Conversations with in the hall suggest that attendees that have been part of the Agile movement for more than a few years feel that innovation experimentation by Agile practitioners is slowing.  That the cycle of inspecting how Agile practices are performed by organizations and teams are being codified and in some cases being practiced as cannon and orthodoxy.  Hallway conversations suggest that the hardening of the rules that some groups are exhibiting is being noticed.  Leading voices are beginning to reemphasize learning and experimentation. One of the reflections of the slowing in evolution of Agile  is a suggestion from a few people that I chatted with that unless you are new or in the business of Agile consulting that attending the conference every two years and reading blogs is enough to keep current. I am not convinced that this suggestion is 100% accurate yet but it maybe soon unless innovation accelerates again.

There were very few negatives.  One downside worth mentioning was that many speakers that I went to see ran out of time. It seemed almost a badge of honor for speakers to announce they were out of time even though they were not done with the material they intended to cover. This included one of the two keynote speakers. Many of the offending parties I would consider professional speakers and know better. Not the end of the world, the ones I really want to know the rest of the story I will track down and interview on the podcast.

As Ernest Hemingway said, “It is good to have an end to journey toward; but it is the journey that matters, in the end.” Agile 2014 is part of my journey of enlightenment.


Categories: Process Management

All Project Work is Probabilistic Work

Herding Cats - Glen Alleman - Thu, 07/31/2014 - 23:55

When we hear about new and possibly innovative ways of improving the probability of success of project work, ask this simple question...

How Do I Make Your Suggestion Actionable on My Project?

With the answer to that question in some unit of measure meanigful to the decision maker (you), the suggestion may be an interesting personal ancedote or observation, but it is not actionable. Let's start with a notion that we can determine what needs to be done to deliver value to the customer. Here's a typical agile view of what Done looks like. More formal descriptions can be found in Intergated Master Schedules or other planning tools, but the Scrum approach is a good start.

Project-kanban-004

So there are a few questions:

  • What's the capacity for work of the team?
  • What's the actual probability each of those stories can be completed in the planned sprint, for the planned release, inside the planned Epic, so the customer start to book the value on the balance sheet to start earning back the cost of that development?
  • What's the estimated cost of all those stories and features, so the customer can be assured the inverstment of the all-on project cost will be earned back on or before the planned break even date for the project?

If we don't have the answers to these questions and others, I'd suggest we're in the co-hacking mode according to Guy Strelitz, where we don't really care about the questions above. If that's your domain, what follows is of little value.

But if your customer is not in the co-hacking domain, there is likely a need to know the answers to the five immutable principles of project success:

  1. What does done look like?
  2. What's the plan to get to done?
  3. Do we have all the resources neded to reach done as planned?
  4. What impediments will we encounter along the way to done and how are we going to handle them?
  5. How are we going to measure physical progress to plan?

The answers to each of these needs to be in units of measure meanigful to the dedcision maker. Without these answers, the probability of success is going to be low.

Related articles 5 Questions That Need Answers for Project Success Can Agile Be Integrated with Governance Based Development Processes? We Can Know the Business Value of What We Build Fit for Purpose, Fit for Use
Categories: Project Management

Grow with Google Play: Scaled Publishing and New App Insights

Android Developers Blog - Thu, 07/31/2014 - 23:55

By Kobi Glick, Google Play team

If you're growing your business on Google Play, the Google Play Developer Console is one of the most important tools at your disposal. At Google I/O, we introduced a number of new changes that give you valuable insight into how your app is performing. Here's an overview of some of the improvements you can now take advantage of.

Publishing API for scaling your app operations

Today we're happy to announce that the Google Play Developer Publishing API is now available to all developers. The API will let you upload APKs to Beta testing, Staged rollout and Production, and integrate publishing operations with your release processes and toolchain. The Publishing API also makes it easier for you to manage your in-app products catalog, provide tablet-specific screenshots, and localize your store listing text and graphics. The Publishing API will help you focus on your core business, with less time managing your releases, even as your business grows to more apps and markets.

Actionable insights at the right time Email notifications for alerts

Recently, we added Alerts in the Developer Console to let you know when there are sudden changes in important stats like app installs, ratings, and crashes. You can now turn on email notifications for Alerts so that, even while you’re not in the Developer Console, you’ll be informed of relevant events before they can have a broader effect on your app. You can turn on email notifications for one or more of your apps under Email Preferences in the Developer Console settings.

New Optimization Tips

You’ll now see new Optimization Tips with instructions when we detect opportunities to improve your app. For example, we’ll let you know when updated versions of APIs you use are available — such as new Google Play in-app billing or Google Maps APIs. For games developers, we’ll also surface opportunities to use Google Play game services that can help improve users’ gaming experience and drive engagement. To see what tips we suggest for you, go to your app in the Developer Console and click on Optimization Tips.

Better data to inform your business decisions Enhanced revenue statistics

To help you better understand your commercial success, we’ve enhanced revenue statistics in the Finance section of the Developer Console. We now let you see the average revenue per paying user (ARPPU) and give you more ways to analyse buyer data, such as comparing returning buyers (i.e., those who also made purchases in the past) to new buyers.

Bulk export of reviews

You can already engage with your users by reading and replying to reviews in the Developer Console and we’ve now added bulk export of reviews so you can download and analyze your app’s reviews en masse. This is particularly useful if you receive a large volume of reviews and want to perform your own sentiment analysis.

Improved stats for beta releases and staged rollouts

Since last year’s launch, you’ve used beta testing to release alpha and beta versions of your app, and staged rollout to gradually launch your app to production. To help you make the most of this feature, we’re now improving the way alpha, beta and staged rollout specific stats are displayed. When viewing your app and crash statistics you can now filter the app version by alpha, beta, or staged rollout to better understand the impact of your testing.

Improved reporting of native crashes

If you develop in native code, we’ve improved the reporting and presentation specifically for native crashes, with better grouping of similar crashes and summarizing of relevant information.

Deep-linking to help drive engagement

Finally, we’ve also added website verification in the Developer Console, to enable deep-linking to your app from search results. Deep-linking helps remind users about the apps they already have. It is available through search for all apps that implement app indexing. For example, if a user with the Walmart Android app searches for “Chromecast where to buy”, they’ll go directly to the Chromecast page in the Walmart app. The new App Indexing API is now open to all Android developers, globally. Get started now.

We hope you find these features useful and take advantage of them so that you can continue to grow your user base and improve your users’ experience. If you're interested in some other great tools for distributing your apps, check out this blog post, or any of the sessions which have now been posted to the Google Developers Channel.
Join the discussion on
+Android Developers


Categories: Programming

Testing on the Toilet: Don't Put Logic in Tests

Google Testing Blog - Thu, 07/31/2014 - 17:59
by Erik Kuefler

This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.

Programming languages give us a lot of expressive power. Concepts like operators and conditionals are important tools that allow us to write programs that handle a wide range of inputs. But this flexibility comes at the cost of increased complexity, which makes our programs harder to understand.

Unlike production code, simplicity is more important than flexibility in tests. Most unit tests verify that a single, known input produces a single, known output. Tests can avoid complexity by stating their inputs and outputs directly rather than computing them. Otherwise it's easy for tests to develop their own bugs.

Let's take a look at a simple example. Does this test look correct to you?

@Test public void shouldNavigateToPhotosPage() {
String baseUrl = "http://plus.google.com/";
Navigator nav = new Navigator(baseUrl);
nav.goToPhotosPage();
assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());
}

The author is trying to avoid duplication by storing a shared prefix in a variable. Performing a single string concatenation doesn't seem too bad, but what happens if we simplify the test by inlining the variable?

@Test public void shouldNavigateToPhotosPage() {
Navigator nav = new Navigator("http://plus.google.com/");
nav.goToPhotosPage();
assertEquals("http://plus.google.com//u/0/photos", nav.getCurrentUrl()); // Oops!
}

After eliminating the unnecessary computation from the test, the bug is obvious—we're expecting two slashes in the URL! This test will either fail or (even worse) incorrectly pass if the production code has the same bug. We never would have written this if we stated our inputs and outputs directly instead of trying to compute them. And this is a very simple example—when a test adds more operators or includes loops and conditionals, it becomes increasingly difficult to be confident that it is correct.

Another way of saying this is that, whereas production code describes a general strategy for computing outputs given inputs, tests are concrete examples of input/output pairs (where output might include side effects like verifying interactions with other classes). It's usually easy to tell whether an input/output pair is correct or not, even if the logic required to compute it is very complex. For instance, it's hard to picture the exact DOM that would be created by a Javascript function for a given server response. So the ideal test for such a function would just compare against a string containing the expected output HTML.

When tests do need their own logic, such logic should often be moved out of the test bodies and into utilities and helper functions. Since such helpers can get quite complex, it's usually a good idea for any nontrivial test utility to have its own tests.

Categories: Testing & QA

Data Flow Diagram (DFD) Tutorial: Texas Hold ‘Em

Software Requirements Blog - Seilevel.com - Thu, 07/31/2014 - 17:11
The data flow diagram is a useful, low-level data model that can show how data is transformed and manipulated through processes. This model does NOT show decisions, nor does it show a sequence of processes. This tutorial will take a commonly understood real-world scenario, a round of Texas Hold ‘Em, and provide step-by-step instructions for […]
Categories: Requirements

Paper: ZooKeeper: Wait-free coordination for Internet-scale systems

Do you really need to roll your own? ZooKeeper: Wait-free coordination for Internet-scale systems: In this paper, we describe ZooKeeper, a service for coordinating processes of distributed applications. Since ZooKeeper is part of critical infrastructure, ZooKeeper aims to provide a simple and high performance kernel for building more complex coordination primitives at the client. It incorporates elements from group messaging, shared registers, and distributed lock services in a replicated, centralized service. The interface exposed by Zoo-Keeper has the wait-free aspects of shared registers with an event-driven mechanism similar to cache invalidations of distributed file systems to provide a simple, yet powerful coordination service.

 

The ZooKeeper interface enables a high-performance service implementation. In addition to the wait-free property, ZooKeeper provides a per client guarantee of FIFO execution of requests and linearizability for all requests that change the ZooKeeper state. These design decisions enable the implementation of a high performance processing pipeline with read requests being satisfied byvlocal servers. We show for the target workloads, 2:1 to 100:1 read to write ratio, that ZooKeeper can handle tens to hundreds of thousands of transactions per second. This performance allows ZooKeeper to be used extensively by client applications.

ZooKeeper achieves throughput values of hundreds of thousands of operations per second for read-dominant workloads by using fast reads with watches, both of which served by local replicas. Although our consistency guarantees for reads and watches appear to be weak, we have shown with our use cases that this combination allows us to implement efficient and sophisticated coordination protocols at the client even though reads are not precedence-ordered and the implementation of data objects is wait-free. The wait-free property has proved to be essential for high performance.

Although we have described only a few applications, there are many others using ZooKeeper. We believe such a success is due to its simple interface and the powerful abstractions that one can implement through this interface. Further, because of the high-throughput of ZooKeeper, applications can make extensive use of it, not only course-grained locking.

Related Articles
Categories: Architecture

Quote of the Day

Herding Cats - Glen Alleman - Thu, 07/31/2014 - 15:31

“Everything has been said before, but since nobody listens we have to keep going back and beginning all over again.” — Andre Gide 1869–1951

It worth repeating, Rudyard Kipling’s Six Trusted Friends

  • What – to do?
  • When – to do it?
  • Where – is it appropriate to do it?
  • Who – should do it?
  • How – to do it?
  • Why – should we do it?

If you're looking for a set of phrases useful for all project work, these are them. Ask them, repeat them, don't take I don't know for an answer.

Related articles Making Improvements Requires Discipline The Calculus of Writing Software for Money
Categories: Project Management

What Is The Difference Between A Schedule and A Plan?

A schedule is not a plan but a plan might have a schedule in it!

A schedule is not a plan but a plan might have a schedule in it!

The first two organizations I worked for called the project schedule the ‘project plan’. A little later when I went to work for an organization that approached project management more formally, I was initially confused when a Gantt chart stopped being a project plan and my trusty plan was replaced by a document indicating how things would be approached rather than what would be done. I still occasionally conflate the concept of a project schedule with a project plan. While the two tools are related, they are different and serve different purposes.

A project plan is a deliverable used to document planning assumptions and as a vehicle to communicate the approved of scope, cost and schedule. Some form of a schedule is typically included in the plan. Inclusion of an early schedule establishes a link between the two deliverables. The Project Management Institute (PMI) indicates that the project plan is a formal, approved document. Formal project plans can include a wide array of sub-plans, including a risk management plan, quality plan or communication plan. Formal, classic project plans can be quite significant documents requiring a lot of effort to prepare. A plan and all of the sub-plans provide a platform for a project manager and stakeholders to develop a common understanding of how a project will be approached and establish roles. Many Agile projects use the Agile Team Charter to set expectations for how the project will be approached at the team level.

A cautionary note: writing and getting a plan signed-off does not ensure that all parties have developed a common understanding. Interaction and conversation are critical steps to developing a common language for the project.

Project schedules come in many forms ranging from simple approaches, such activity lists and time tables, to highly complex forms that include task network-based schedules and Critical Path Methods (CPM). A common thread in most schedules is that features, tasks and activities (or some subset) are documented and connected as a tool to guide the team and communicate progress. Agile teams use prioritized backlogs and release plans as schedules and while other methods use techniques such as milestone charts, task lists, Gantt chats and/or CPM (this only scratches the surface). Schedules act as tools to guide activities in a project, to answer the “when” questions and to help answer the “how much will this cost” questions.

Plans are a mechanism to help teams and project leaders consider how the project will be approached, to define roles and to begin to establish a common understanding between everyone involved. Project schedules reflect how the work will get done and when it will get done. Schedules reflect tactical planning, while plans take a more strategic view. Like planning, all projects use some form of scheduling technique. Team charters, backlogs, release plans, iteration backlogs, task lists or Kanban boards or project plan documents and detailed project schedules, reflect the difference in our approach and philosophy.


Categories: Process Management

Google I/O 2014 App Source Code Now Available

Android Developers Blog - Wed, 07/30/2014 - 22:24

By Bruno Oliveira, Tech Lead of the I/O app project

The source code for the 2014 version of the Google I/O app is now available. Since its first release on Google Play a few weeks before the conference, the I/O app was downloaded by hundreds of thousands of people, including on-site attendees, I/O Extended event participants and users tuning in from home. If one of the goals of the app is to be useful to conference attendees, the other primary goal is to serve as a practical example of best practices for Android app design and development.

In addition to showing how to implement a wide variety of features that are useful for most Android apps, such as Fragments, Loaders, Services, Broadcast Receivers, alarms, notifications, SQLite databases, Content Providers, Action Bar and the Navigation Drawer, the I/O app source code also shows how to integrate with several Google products and services, from the Google Drive API to Google Cloud Messaging. It uses the material design approach, the Android L Preview APIs and full Android Wear integration with a packaged wearable app for sending session feedback.

To simplify the process of reusing and customizing the source code to build apps for other conferences, we rewrote the entire sync adapter to work with plain JSON files instead of requiring a server with a specific API. These files can be hosted on any web server of the developer's choice, and their format is fully documented.

Storing and syncing the user's data (that is, the personalized schedule) is crucial part of the app. The source code shows how user data can be stored in the Application Data folder of the user's own Google Drive account and kept in sync across multiple devices, and how to use Google Cloud Messaging to trigger syncs when necessary to ensure the data is always fresh.

The project includes the source code to the App Engine app that can be reused to send GCM messages to devices to trigger syncs, as well as a module (called Updater) that can be adapted to read conference data from other backends to produce the JSON files that are consumed by the I/O app.

We are excited to share this source code with the developer community today, and we hope it will serve as a learning tool, a source of reusable snippets and a useful example of Android app development in general. In the coming weeks we will post a few technical articles with more detailed information about the IOSched source code to help bring some insight into the app development process. We will continue to update the app in the coming months, and as always, your pull requests are very welcome!


Join the discussion on
+Android Developers


Categories: Programming

Preventing the Dogpile Effect - Problem and Solution

This is a guest repost Przemek Sobstel, who believes that dogpile effect issue is not covered enough, especially in the PHP world. Orignal article: Preventing dogpile effect.

The Dogpile effect occurs when cache expires and websites are hit by numerous requests the same time. From my own experiences working on big-traffic websites this is what I consider best the best solution. It was used sucessfully in the wild and it worked. Many people mention storing two redundant values FRESH + STALE, but for big traffic websites it was killing our network. We thought it worth sharing our solution and starting a discussion for sharing experiences.

Preventing Dogpiles
Categories: Architecture

Publish Book. Done. Next.

NOOP.NL - Jurgen Appelo - Wed, 07/30/2014 - 14:42
Publish Book

One of the best thing about finishing a book is finishing the research. No more skimming through dozens of books–and thousands of pages–to find two or three nuggets of wisdom. No more digging through web pages, dictionaries, and Wikipedia entries, to get the details right between this word and that word. No more flipping through magazines, blogs, and news sites, just to see if my writing is still up-to-date on this topic or that topic.

Sorry, that’s not entirely true

The post Publish Book. Done. Next. appeared first on NOOP.NL.

Categories: Project Management

How To Make Decisions

Herding Cats - Glen Alleman - Wed, 07/30/2014 - 12:38

Decisions are about making Trade Offs for the project. These decisions are about:

  • Evaluating alternatives.
  • Integrating and balancing all the considerations (cost, performance, Producibility, testability, supportability, etc.).
  • Developing and refining the requirements, concepts, capabilities of the product or services produced by the project or product development process.
  • Making trade studies and the resulting trade offs that enables the selection of the best or most balanced solution to fulfill the business need or accomplishment of the mission.

The purpose of this decision making process is to:

  • Identify the trade-offs – the decisions to be made – among requirements, design, schedule, and cost.
  • Establish the level of assessment commensurate with cost, schedule, performance, and risk impact based on the value at risk for the decision.
    • Low value at risk, low impact, simple decision making – possibly even gut feel.
    • High value at risk, high impact, the decision-making process must take into account these impacts.

Trade-offs are essential to strategy. They create the need for choice and purposefully limit what a company offers.

It is only by assessing the impacts of these tradeoffs can the products or solutions of the projects be guided. Otherwise, just producing the requirements has no real purpose - no strategic purpose connected to the needed capabilities. ‡

Making decisions about capabilities and resulting requirements is the starting point for discovering what DONE looks like, by:

  • Establishing alternatives for the needed performance and functional requirements.
  • Resolving conflicts between these requirements in terms of the product’s delivered capabilities.

Decisions about the functional behaviours and their options is next. These decisions:

  • Determine preferred set of requirements for the needed capabilities. This of course is an evolutionary process as requirements emerge, working products are put to use, and feedback is obtained.
  • Determine the customer assesses requirements for lower-level functions as each of the higher-level capabilities are assessed.
  • Evaluate alternatives to each requirement, each capability, and the assessed value of each capability – in units of measure meaningful to the decision makers.

Then comes the assessment the cost effectiveness of each decision:

  • Develop the Measures of Effectiveness (MOE) and Measures of Performance (MOP) for each decision.
  • Identify the critical Measures of Effectiveness of each decision in fulfilling the project’s business goal or mission. These Technical Performance Measures are used to assess the impact of each decision on the produced value of the project.

Each of these steps is reflected in the next diagram.

Screen Shot 2014-07-28 at 8.08.44 AM

Value of This Approach

When we hear that estimates are not needed to make decisions, we need to ask how the following questions can be answered:

  • How can we have a systematized thought process, where the decisions are based on measureable impacts?
  • How can we clarify our options, problem structure, and available trade-offs using units of measure meaningful to the decision makers?
  • How can we improve communication of ideas and professional judgment within our organization through a shared exchange of the impacts of our decisions?
  • How can we improve communication of rationale for each decision to others outside the organization?
  • How can we be assured of our confidence that all available information has been accounted for in a decision?

The decision making process is guided by the identification of alternatives

Decision-making is about deciding between alternatives. These alternatives need to be identified, assessed, and analyzed for their impact on the probability of success of the project.

These impacts include, but are not limited to:

  • Performance
  • Schedule
  • Cost
  • Risk
  • Affordability
  • Producibility
  • And all the other …ilities associated with the outcomes of the project

The effectiveness of our decision making follows the diagram below:

  Screen Shot 2014-07-28 at 8.05.58 AM

In the End - Have all the Alternatives Been Considered?

Until there is a replacement for the principles of Microeconomics, for each decision made on the project, we will need to know the impact on cost, schedule, technical parameters, and other attributes of that decision. To not know those impacts literally violates the principles of microeconomics and the governance framework of all business processes, where the value at risk is non-trivial.

As Shim says think about it

Screen Shot 2014-07-28 at 12.26.24 PM

When you hear planning ahead, by assessing our altenatives is overrated, think again.

‡ What is Strategy? , M. E. Porter, Harvard Business Review, Volume 74, Number 6, pp. 61-68.

Connecting IT and Business Strategy, Glen B. Alleman, 5/12/2007

† Derived from Module J: Trade Study Process, Systems Engineering, Boeing.

Related articles Agile Project Management Concept of Operations First, then Capabilities, then Requirements The Value of Information Critical Thinking Skills Needed for Any Change To Be Effective Why Project Management is a Control System
Categories: Project Management

100+ Motivational Quotes to Inspire Your Greatness

I updated my Motivational Quotes page.

I’ve got more than 100 motivational quotes on the page to help you find your inner-fire.

It’s not your ordinary motivational quotes list.  

It’s deep and it draws from several masters of inspiration including Bruce Lee, Jim Rohn, and Zig Ziglar.

Here is a sampling of some of my personal favorite motivational quotes ..

“If you always put limit on everything you do, physical or anything else. It will spread into your work and into your life. There are no limits. There are only plateaus, and you must not stay there, you must go beyond them.” – Bruce Lee

“Knowing is not enough; we must apply. Willing is not enough; we must do.” - Johann Wolfgang von Goethe

“Kites rise highest against the wind; not with it.” – Winston Churchill

“To hell with circumstances; I create opportunities.” – Bruce Lee

“Our greatest glory is not in never falling but in rising every time we fall.” – Confucius

“There is no such thing as failure. There are only results.” – Tony Robbins

“When it’s time to die, let us not discover that we have never lived.” -Henry David Thoreau

“People who say it cannot be done should not interrupt those who are doing it.” – Anonymous

“Motivation alone is not enough. If you have an idiot and you motivate him, now you have a motivated idiot.” – Jim Rohn

“If you love life, don’t waste time, for time is what life is made up of.” – Bruce Lee

For more quotes, check out my motivational quotes page.

It’s a living page and at some point I’ll do a complete revamp.

I think in the future I’ll organize it by sub-categories within motivation rather than by people.I think at the time it made sense to have words of wisdom by various folks, but now I think grouping motivational quotes by sub-categories would work much better, especially when there is such a large quantity of quotes.

Categories: Architecture, Programming