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

Can There Be Actionable Suggestions Without Evidence of Them Working?

Herding Cats - Glen Alleman - Sat, 07/19/2014 - 01:38

Visiting the Montana State Museum of the Rockies this weekend and came across this sign in an exhibit. 

Now writing software for money is not this kind of science, but it is closely related to engineering and the enablement of engineering processes in our domain - things that fly away, swim away, drive away, and the enterprise IT systems that support those outcomes.

Evidence

When we hear about some new way to do something around managing projects that spend other peoples money, we do need to ask the questions posed by the sign above.

Is there any evidence that the suggested way - this new alternative of doing something - has the desired outcomes?

No? Then it's going to be difficult for those of us working in a domain that provides mission critical solutions - ERP, embedded software, infrastructure that other systems depend on - to know how to assess those suggestions.

The process of asking and answering a question like that is found in the Governance paradigm. Since our role is to be stewards of our customer's money in the delivery of value in exchange for that money, it's a legitimate question and deserves a legitimate answer. Without an answer, or at least and answer than can be tested outside the personal anecdotal experience of the proposer, it tends to be unsubstantiated opinion. 

Related articles Performance Based Management Positive Deviance Can Agile Be Integrated with Governance Based Development Processes? What Software Domain Do You Work In? The Myth of Incremental Development How to "Lie" with Statistics What Does "Done" Look Like? Why is Statistical Thinking Hard? If We're Going To Make Improvements, We Have To Be Able To Calculate Real Numbers
Categories: Project Management

Stand-up Meetings: Add-ons

Stay focused!

Stay focused!

 

There are very few add-ons that can make a daily stand-up meeting better. In fact most add-ons shift the focus of the meeting and could easily be classified as process problems. However, there are two add-ons that can add value to the stand-up meeting process: trolling for risks and hand-offs.

Trolling for risks. Anyone that has ever felt responsibility for the outcome of a project has had that nagging feeling that something was lurking just over the horizon that could reduce the value you are delivering. Project risks reflect the potential for something to go wrong. No one wants to have a risk that should be seen coming to catch them off guard. Therefore I periodically add a fourth question to the stand-up meeting questions: “Are there any project risks you are more concerned about this sprint than last sprint?” The goal is expose any new risks or any risks that are becoming more risky. At a project level I suggest adding this to the stand-up discussion once per two week sprint and do not let the conversation expand beyond the 15 minute time box. If the project has suddenly become so risky that more time is needed, I would suggest treating the changed risk status as a blocker and have the scrum master pursue identifying the root cause so that specific action can be taken. Stand-ups for a program (very large project or a related group of projects) may need to monitor risk on a daily basis.

Hand-offs. Project teams are often distributed across continents, which can be used to a team’s advantage so that work begun in one time zone can be handed off and to be continued at the beginning of another team member’s day. This technique is often called “following the sun.” In order for this technique to work, the team members that are involved in the hand-off must understand that the hand-off is occurring, the goal of the shared task and the current status of the work. The daily stand-up meeting plays a critical role in this process. Involved team members can use their update to alert those they are handing work off to about the current status of their shared task or to schedule follow-on discussions if a more in-depth hand-off is needed. One common example of this practice is when developers are in one location and testers in another. The approach is first planned in sprint planning then coordinated during the daily stand-up meeting and other person-to-person interactions. The daily stand-up meeting generally acts as a formal control mechanism while conversation outside the meeting is less formal and more collaborative.

The stand-up meeting serves a very specific set of planning and coordination purposes. Add-ons generally push the daily stand-up meeting away from that purpose therefore become process problems. There are a few add-ons that fit well within the purpose of the meeting and the 15 minute time box. These add-ons focus on planning and coordinating and help the team get their work done rather than reporting on how the work is being done.


Categories: Process Management

Episode 206: Ken Collier on Agile Analytics

Johannes Thönes talks to Dr. Ken Collier, Director of Agile Analytics at ThoughtWorks about Agile Analytics. The outline includes: descriptive analytics, predictive analytic and prescriptive analytics; artificial intelligence, machine learning, data mining and statistics; collaborative filtering; data science and data scientists; data warehousing and business intelligence; online analytical processing (OLAP), extract transform load (ETL), feature […]
Categories: Programming

Stuff The Internet Says On Scalability For July 18th, 2014

Hey, it's HighScalability time:


The one is many. Lichen composed of possibly 400 distinct species.
  • Quotable Quotes:
    • The Master Switch: Selling radio sets—the old revenue model—was a good if limited business, for ultimately few households would need more than one radio every few years. But advertising revenues could expand indefinitely—or so it seemed then.
    • Larry Page: It’s pretty difficult to solve big problems in four years. I think it’s probably pretty easy to do it in 20 years. I think our whole system is setup in a way that makes it difficult for leaders of really big companies.

  • The Master Switch: The inventors we remember are significant not so much as inventors, but as founders of “disruptive” industries, ones that shake up the technological status quo. Through circumstance or luck, they are exactly at the right distance both to imagine the future and to create an independent industry to exploit it.

  • You thought you were clever and safe? Reality doesn't like that. The fallacy of distributed transactions: In other words, as far as the queue is concerned, the transaction committed, and the message is gone. As far as the database is concerned, that transaction was rolled back, and never happened. Of course, the chance that something like that can happen in one of your systems? Probably one in a million.

  • How do you make Cassandra 50% faster? You add batching of replies. You fix your thread pools. And you get rid of unecessary endcoding and decoding phases like with Thrift. Of course now the bottleneck has moved and the process starts again.

  • Everyday Algorithms: Elevator Allocation. Though I'm pretty sure my contextualized and personalized elevator scheduling goes something like: for him, slow as possible. And they and the crosswalk lights must be in cahoots, because I get the same fine service.

  • Simon Wardley: Anyhow, this is what I don't get. Micro services has become a big thing - good. So, why do we have to continuously create 'new' terms to describe what is already happening? < Why have new songs when they use all the same words? What changes is the context. A new binding requires a new word. It's like a linguistic method of versioning. 10 years ago all the words around that eras version of microservices would be different, so we need a new word now to reflect a new world.

  • Programmers really want the database to work as a queue. It just never works in the end. But if you are Antirez and are a programmer and have your own database then you can make that happen. Queues and databases

  • Another case of breaking one thing in to two parts and then arguing which part is more important. In reference to the debate over Linus' quote on data structures: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." < Good and evil. Light and dark. Mind and Body. Starsky and Hutch. They are defined in terms of each other and make no sense without each other. They are a single system. 

  • New russian 8-core CPU. It may not be the fastest CPU, but it won't break in the field and hardly ever jams when covered in mud or sand.

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

Why Testing in Women Testers Magazine

I have an article in a new online magazine, Women Testers, the July 2014 edition. My article is called “Why Testing?”

When I was a tester or a developer, I asked many questions. As a project manager, program manager or consultant, I still ask many questions. One of those is the Why question. This article examines that question from a number of perspectives.

Go read that article and many others from people such as Alexandra Moreira, Bolette Stubbe Teglbjærg, Smita Mishra, Sara Tabor, Karen N. Johnson, and Mike Lyles.

I bet you’ll enjoy it!

Categories: Project Management

My Zero-Tolerance to Bureaucracy Policy

NOOP.NL - Jurgen Appelo - Fri, 07/18/2014 - 14:19
Zero-Tolerance to Bureaucracy

Sometimes, event organizers ask me to fill out a form asking me for my company name, address, bank account number, bank name, tax number, and much more. They tell me they need this information in order to make their payment to me later. But I think this is a bit silly.

The post My Zero-Tolerance to Bureaucracy Policy appeared first on NOOP.NL.

Categories: Project Management

Porting Your Android Wear Developer Preview Code to the Latest Support Library

Android Developers Blog - Fri, 07/18/2014 - 01:18

Today’s post on #AndroidWear is from +Wayne Piekarski.

Now that the full Android Wear SDK is available, it’s time to port your existing wearable-enabled notification code from the Developer Preview. In the process, you’ll switch to using the latest Android support library, and there are some small API changes that will require you to update your code. This article will show you how to update my previous code samples that were released earlier for stacks and pages, which you can use to guide the conversion of your own code as well.

To get started with an existing project in Android Studio, you should update to the 0.8 or later release. You also need to make sure you’ve downloaded the Google Support Library version 20 or later from the SDK Manager. Since this is only a notification-based example, there’s no need to download the full Android Wear SDK, which is only needed if you want to create an APK to run on the wearable device.

Unix diff output is used to show the necessary changes in an easy to understand way. Do not copy the + or - symbols at the start of each line, and ignore the lines starting with @@ which are used to indicate the line number that changed. For the curious, I used the following command to generate the diff output from the last commit in my GIT repository (the -U1 shows one line of context to keep the output simple):

git show HEAD -U1

Gradle changes

To add the new support-v4 library, you need to edit your build.gradle file like so:

@@ -24,2 +24,3 @@ dependencies {
     compile 'com.android.support:appcompat-v7:19.+'
+    compile 'com.android.support:support-v4:20.0+'
 }

Make sure you remove the wearable-preview-support.jar that was provided with the Developer Preview from your libs directory and build.gradle file, since these features are now in the standard support library.

Package imports

Since the APIs and package names have changed, the import statements at the top of MainActivity.java need to be adjusted like this:

@@ -7,3 +7,2 @@ import android.view.MenuItem;
-import android.support.v4.app.NotificationCompat;
 import android.app.Notification;
@@ -13,4 +12,9 @@ import android.graphics.Bitmap;
 import android.graphics.BitmapFactory;
-import android.preview.support.v4.app.NotificationManagerCompat;
-import android.preview.support.wearable.notifications.WearableNotifications;
+import android.support.v4.app.NotificationCompat;
+import android.support.v4.app.NotificationManagerCompat;
+
+// Extra dependencies needed for the pages example
+import java.util.ArrayList;
+import java.util.List;
+import android.support.v4.app.NotificationCompat.BigTextStyle;
Stacking notifications

Since the preview SDK, we have simplified how notifications are implemented. The existing NotificationCompat.Builder() was extended to support groups directly, instead of a separate WearableNotifications class. The steps are a lot simpler, as can be seen with the following changes to showStackNotifications():

@@ -63,3 +67,3 @@ public class MainActivity extends ActionBarActivity {
         // Group notification that will be visible on the phone
-    NotificationCompat.Builder builderG = new NotificationCompat.Builder(this)
+    Notification summaryNotification = new NotificationCompat.Builder(this)
             .setContentTitle("2 Pet Notifications")
@@ -67,5 +71,5 @@ public class MainActivity extends ActionBarActivity {
             .setSmallIcon(R.drawable.ic_launcher)
-                .setLargeIcon(bitmapMila);
-    Notification summaryNotification = new WearableNotifications.Builder(builderG)
-            .setGroup(GROUP_KEY_MESSAGES, WearableNotifications.GROUP_ORDER_SUMMARY)
+                .setLargeIcon(bitmapMila)
+            .setGroup(GROUP_KEY_MESSAGES)
+            .setGroupSummary(true)
             .build();
@@ -76,3 +80,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0);
-    NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this)
+    Notification notification1 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Treat Fed", viewPendingIntent1)
@@ -81,4 +85,3 @@ public class MainActivity extends ActionBarActivity {
                     + "Can we have steak?")
-                .setSmallIcon(R.drawable.ic_launcher);
-    Notification notification1 = new WearableNotifications.Builder(builder1)
+            .setSmallIcon(R.drawable.ic_launcher)
             .setGroup(GROUP_KEY_MESSAGES)
@@ -89,3 +92,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+2, viewIntent2, 0);
-    NotificationCompat.Builder builder2 = new NotificationCompat.Builder(this)
+    Notification notification2 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Water Filled", viewPendingIntent2)
@@ -93,4 +96,3 @@ public class MainActivity extends ActionBarActivity {
             .setContentText("Can you refill our water bowl?")
-            .setSmallIcon(R.drawable.ic_launcher);
-        Notification notification2 = new WearableNotifications.Builder(builder2)
+            .setSmallIcon(R.drawable.ic_launcher)
             .setGroup(GROUP_KEY_MESSAGES)
Page notifications

Page notifications have also changed to use a WearableExtender() class instead of the WearableNotifications class, as can be seen here in showPageNotifications():

@@ -151,3 +153,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0);
-    NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this)
+    Notification notification1 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Returned", viewPendingIntent1)
@@ -155,5 +157,4 @@ public class MainActivity extends ActionBarActivity {
             .setContentText("You have " + numOverdue + " books due at the library")
-            .setSmallIcon(R.drawable.ic_launcher);
-    Notification notification1 = new WearableNotifications.Builder(builder1)
-            .addPages(extras)
+                .setSmallIcon(R.drawable.ic_launcher)
+            .extend(new NotificationCompat.WearableExtender().addPages(extras))
             .build();
Conclusion

If you want to download the final source code of showStackNotifications() and showPageNotifications(), you can download the MainActivity.java file. You can build this file easily by creating a new project in Android Studio, adding the support library, and then copying in this MainActivity.java.

As you can see, porting this previous code over to the latest Android Wear SDK is really easy! It should take you hardly any time at all to get your experimental applications ported over and ready for publishing on the Google Play!


Join the discussion on
+Android Developers


Categories: Programming

The "Just In Time" Theory of User Behavior

Coding Horror - Jeff Atwood - Fri, 07/18/2014 - 01:05

I've long believed that the design of your software has a profound impact on how users behave within your software. But there are two sides to this story:

  • Encouraging the "right" things by making those things intentionally easy to do.

  • Discouraging the "wrong" things by making those things intentionally difficult, complex, and awkward to do.

Whether the software is doing this intentionally, or completely accidentally, it's a fact of life: the path of least resistance is everyone's best friend. Learn to master this path, or others will master it for you.

For proof, consider Dan Ariely's new and amazing book, The (Honest) Truth About Dishonesty: How We Lie to Everyone – Especially Ourselves.

Indeed, let's be honest: we all lie, all the time. Not because we're bad people, mind you, but because we have to regularly lie to ourselves as a survival mechanism. You think we should be completely honest all the time? Yeah. Good luck with that.

But these healthy little white lies we learn to tell ourselves have a darker side. Have you ever heard this old adage?

One day, Peter locked himself out of his house. After a spell, the locksmith pulled up in his truck and picked the lock in about a minute.

“I was amazed at how quickly and easily this guy was able to open the door,” Peter said. The locksmith told him that locks are on doors only to keep honest people honest. One percent of people will always be honest and never steal. Another 1% will always be dishonest and always try to pick your lock and steal your television; locks won’t do much to protect you from the hardened thieves, who can get into your house if they really want to.

The purpose of locks, the locksmith said, is to protect you from the 98% of mostly honest people who might be tempted to try your door if it had no lock.

I had heard this expressed less optimistically before as

10% of people will never steal, 10% of people will always steal, and for everyone else … it depends.

The "it depends" part is crucial to understanding human nature, and that's what Ariely spends most of the book examining in various tests. If for most people, honesty depends, what exactly does it depend on? The experiments Ariely conducts prove again and again that most people will consistently and reliably cheat "just a little", to the extent that they can still consider themselves honest people. The gating factor isn't laws, penalties, or ethics. Surprisingly, that stuff has virtually no effect on behavior. What does, though, is whether they can personally still feel like they are honest people.

This is because they don't even consider it cheating – they're just taking a little extra, giving themselves a tiny break, enjoying a minor boost, because well, haven't they been working extra specially hard lately and earned it? Don't they of all people deserve something nice once in a while, and who would even miss this tiny amount? There's so much!

These little white lies are the path of least resistance. They are everywhere. If laws don't work, if ethics classes don't work, if severe penalties don't work, how do you encourage people to behave in a way that "feels" honest that is actually, you know, honest? Feelings are some pretty squishy stuff.

It's easier than you think.

My colleagues and I ran an experiment at the University of California, Los Angeles. We took a group of 450 participants, split them into two groups and set them loose on our usual matrix task. We asked half of them to recall the Ten Commandments and the other half to recall 10 books that they had read in high school.

Among the group who recalled the 10 books, we saw the typical widespread but moderate cheating. But in the group that was asked to recall the Ten Commandments, we observed no cheating whatsoever. We reran the experiment, reminding students of their schools' honor codes instead of the Ten Commandments, and we got the same result. We even reran the experiment on a group of self-declared atheists, asking them to swear on a Bible, and got the same no-cheating results yet again.

That's the good news: a simple reminder at the time of the temptation is usually all it takes for people to suddenly "remember" their honesty.

The bad news is Clippy was right.

In my experience, nobody reads manuals, nobody reads FAQs, and nobody reads tutorials. I am exaggerating a little here for effect, of course. Some A+ students will go out of their way to read these things. That's how they became A+ students, by naturally going the extra mile, and generally being the kind of users who teach themselves perfectly well without needing special resources to get there. When I say "nobody" I mean the vast overwhelming massive majority of people you would really, really want to read things like that. People who don't have the time or inclination to expend any effort at all other than the absolute minimum required, people who are most definitely not going to go the extra mile.

In other words, the whole world.

So how do you help people who, like us, just never seem to have the time to figure this stuff out becase they're, like, suuuuper busy and stuff?

You do it by showing them …

  • the minumum helpful reminder
  • at exactly the right time

This is what I've called the "Just In Time" theory of user behavior for years. Sure, FAQs and tutorials and help centers are great and all, but who has the time for that? We're all perpetual intermediates here, at best.

The closer you can get your software to practical, useful "Just In Time" reminders, the better you can help the users who are most in need. Not the A+ students who already read the FAQ, and studied the help center intently, but those users who never read anything. And now, thanks to Dan Ariely, I have the science to back this up. Even something as simple as putting your name on the top of a form to report auto insurance milage, rather than the bottom, resulted in a mysterious 10% increase in average miles reported. Having that little reminder right at the start that hey, your name is here on this form, inspired additional honesty. It works.

Did we use this technique on Stack Overflow and Stack Exchange? Indeed we did. Do I use this technique on Discourse? You bet, in even more places, because this is social discussion, not technical Q&A. We are rather big on civility, so we like to remind people when they post on Discourse they aren't talking to a computer or a robot, but a real person, a lot like you.

When's the natural time to remind someone of this? Not when they sign up, not when they're reading, but at the very moment they begin typing their first words in their first post. This is the moment of temptation when you might be super mega convinced that someone is Wrong on the Internet. So we put up a gentle little reminder Just In Time, right above where they are typing:

Then hopefully, as Dan Ariely showed us with honesty, this little reminder will tap into people's natural reserves of friendliness and civility, so cooler heads will prevail – and a few people are inspired to get along a little better than they did yesterday. Just because you're on the Internet doesn't mean you need to be yelling at folks 24/7.

We use this same technique a bunch of other places: if you are posting a lot but haven't set an avatar, if you are adding a new post to a particularly old conversation, if you are replying a bunch of times in the same topic, and so forth. Wherever we feel a gentle nudge might help, at the exact time the behavior is occurring.

It's important to understand that we use these reminders in Discourse not because we believe people are dumb; quite the contrary, we use them because we believe people are smart, civil, and interesting. Turns out everyone just needs to be reminded of that once in a while for it to continue to be true.

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

How Stand-up Meeting Go Wrong: Process Issues

Stand-up Meetings are not just a presentations.

Stand-up meetings are not just a set presentations to scrum masters.

A team’s daily stand-up meeting is an execution of a process, a series of steps taken to achieve a purpose.  Stand-up meetings lose effectiveness when they don’t follow a process, when participants try to multi-task during the meeting, treat the scrum master like manager or when stand-up meeting becomes a status meeting. All of these problems are process problems.

Stand-up Meetings Without a Process  Stand-up meetings are daily planning meetings. During the meeting the team sorts out what has been completed, what will be accomplished in the near term and whether there are any “blockers” inhibiting progress.  There are numerous approaches that can be used to do stand-up meetings, including the famous three questions approach and walking the board. The team should leverage more than one technique on a regular basis to keep the meeting fresh.  What should never happen is for a team to abandon structure and just hope team members will share all pertinent planning and problem information.  The job of a scrum master/coach is to ensure the team has a pallet of stand-up techniques and that those techniques are used.

Multi-tasking  One of reasons stand-up meetings work efficiently is that they are short and focused.  The meeting should be 15 minutes (or less).  Nearly everyone can focus on one thing for 15 minutes without doing something else (like day trading or checking email on their smart phone).   I strongly urge all teams I work with to ban smart phones or any other electronic tools during the meeting UNLESS absolutely needed to view the team board (video, teleconference or Agile tool).  I have even gone as far to suggest that phones be put on the floor during the stand-up meeting.  Fractured attention reduces interaction. Recently I was walking through Little Italy in New York City after dinner.  As I walked past restaurant after restaurant, I noticed that many diners were sharing their attention between their phones and their dinner party, reducing the conversation at each table.  Stand-up meetings ONLY work when the team is sharing and listening.

Reporting to the Scrum Master  Stand-ups are a team meeting.  The team members talk to and interact with each other.  Occasionally the meeting might require some facilitation, however the communication and interaction needs to be between team members. They are ones writing the code, testing the software, building the hardware or writing documentation.  The scrum master/coach is the facilitator, not the focus of the meeting.  Team members must address each other not the facilitator.  One technique I learned early in my coach career was to stand behind the team rather than in front of the team or in front of the team board.  Team members will tend not turn around to face the coach, so they will make eye contact with their team members instead.

Status Meeting  The single worst process problem is converting the stand-up into a status meeting (or any other kind of meeting).  Just don’t make this mistake.  If a meeting to collect and discuss the status of a project is needed, first do the stand-up meeting, end the stand-up meeting and then reconvene a separate meeting. The Scrum master/coach should draw a very distinct line between meetings, even if people don’t leave the room so that no one confuses the purpose between the two sessions. For example, in organizations where stand-ups are done standing up, I have had team members sit down to mark the change of meetings.  Another example, when I have done distributed stand-ups, I invite everyone that needs to attend the second meeting to hang up and re-dial.  This clean break makes it easier for people that don’t absolutely need to be involved to get back to work.

The practice of stand-up meetings is one of the first techniques most organizations adopt when they begin to implement Agile.  Because of the simplicity of the technique, organizations forgo coaching or training on how to do stand-up meetings. They rely instead on the best efforts of everyone involved.  Without coaching stand-up meetings can be implemented poorly, robbing the organization of the benefits of the technique.


Categories: Process Management

First experiences with OpenStack

Agile Testing - Grig Gheorghiu - Thu, 07/17/2014 - 21:37
We hit a big milestone this week, as we started to use OpenStack as a private cloud, intially just for QA/integration environments. Up to now we've been creating KVM machines semi-manually, which used to take minutes. Now we cut down that process to seconds, calling the Nova API from the command line, e.g.:

$ nova boot --image precise-image --flavor www --key_name mykey --nic net-id=3eafbd4f-0389-4c5b-93ba-7764742ee8cd www1.qa1

Once an instance is provisioned, we bootstrap it with Chef:

$ knife bootstrap www1.qa1.mydomain.com -x ubuntu --sudo -E qa1 -N www1.qa1 -r "role[base], role[www]"

Our internal network architecture is fairly complex, so my colleague Jeff Roberts spent quite some time bending OpenStack Neutron to his will (in conjunction with Open vSwitch) in order to support our internal VLANs. The OpenStack infrastructure has been stable so far, and it's just such a pleasure to do everything via an API and not to spin VMs up manually. Being back to working with a (private) cloud feels good.

This is just version 1.0 of our OpenStack rollout. Soon we'll start spinning up one environment at a time using chef-metal and fog  and we'll also integrate instance + environment spin-up with Jenkins. Exciting times ahead!

Upgrade now to Calendar APIv3

Google Code Blog - Thu, 07/17/2014 - 19:30
Cross-posted from the Google Apps Developers Blog

Back in 2011, we launched Calendar APIv3, which offers developers several improvements over older versions of the API, including better support for recurring events and lightweight resource representation in JSON. At that same time, we also announced that the older versions of the API – v1 and v2 – would be entering a three-year deprecation period in order to give developers time to migrate to the new version. Those three years are coming to an end, and on November 17, the v1 and v2 endpoints will be shut down. If you haven’t already done so, you should migrate your application now to APIv3 so that it continues to work after that date (and to start taking advantage of all that the new API offers!).

For additional resources, check out our Migration and Getting started guides. And if you have questions or issues, please reach out to us on StackOverflow.com, using tag #google-calendar.

By Lucia Fedorova, Calendar API Team

Lucia Fedorova is a Tech Lead of the Google Calendar API team. The team focuses on providing a great experience to Google Calendar developers and enabling new and exciting integrations.

Posted by Louis Gray, Googler
Categories: Programming

Do Teams Gel or Jell?

In my role as technical editor for agileconnection.com, I have the opportunity to read many terrific articles. I also have the opportunity to review and comment on those articles.

One such comment is what do teams do? Do they “gel” or do they “jell”?

Gel is what you put in hair. When you “gel” things, you create a thick goo, like concrete. Teams are not a thick goo. Teams are flexible and responsive.

Jell is what you want teams to do. You want them firm, but not set in concrete. When teams jell, they might even jiggle a little. They wave. They adapt. They might even do a little dance, zigging here, zapping there.

You want to keep the people in the teams as much as possible, so you flow work through the teams. But you want the people in the teams to reconsider what they do on a regular basis. That’s called retrospecting. People who have their feet in concrete don’t retrospect. They are stuck. People who are flexible and responsive do.

So, think about whether you have a gelled or a jelled team. Maybe I’m being a nitpicker. I probably am. Our words mean something.

If you have an article you’d like to publish, send it to me. You and I will craft it into something great. Whether or not your team jells.

 

Categories: Project Management

The Myth of Incremental Development

Herding Cats - Glen Alleman - Thu, 07/17/2014 - 17:07

Screen Shot 2014-07-13 at 6.27.34 PMIn the agile world there is a common notion that incremental delivery is a desired approach. Many taught rapid release, even multiple releases a day.

The question is two fold. Can the customer accept the release into use and the other does the customer have the ability to make use of the incremental capabilities of these releases?

Let's start with the incremental release. I know the picture to the left is  considered a metaphor by some. But as a metaphor it's a weak. Let's look a a few previous posts. Another Bad Agile Analogy, Use, Misuse, and Danger of Metaphor. Each of these presents some issues with using Metaphors.

But let's be crystal clear here. Incremental development in the style of the bottom picture may be a preferred method, once the customer agrees. Much of the reterotic around agile assumes the customer can behave in this way, without looking outside the ancedotal and many times narrow experiences of the those making that suggestion. For agile to succeed in the enterprise and mission critical product and project domain, testing the applicability of both pictures is needed.

Ask the customer if they are willing to use the skateboard while waiting for the car? Otherwise you have a solution looking for a problem to solve.

Now to the bigger issue. In the picture above, the top series is a linear development and the bottom an iterative or incremental depending on where you work. Iterating on the needed capabilities to arrive at the car. Or incrementally delivering a mode of transporatation.

The bottom's increment shows 5 vehicles produced by the project. The core question that is unanswered is does the customer want a skate board, scooter, bicycle, motorcycle, and then a car for transportation. If yes, no problem. But if the customer actually needs a car to conduct business, drive the kids to school, or arrive at the airport for your vacation trip.

The failure of the metaphor and most metaphors is they don't address the reason for writing software for money

Provide capabilities for the business to accomplish something - Capabilities Based Planning

The customer didn't buy requirements, software, hardware, stories, features, or even the agile development process. They bought a capability to do something. Here's how to start that process.

Capabilities Based Planning

Here's the outcome and an insurnace provider network enrollemtn ERP system.

Capabilities Map

Producing skateboards, then scooters, then bicycles and then finally the car isn't going to meet the needs of the customer if they want a car or a fleet of cars. In the figure above the Minimal Viable Features, aren't features they are capabilities. For example this statement is a minimal viable product is likey a good description of a Beta Feature. Could be connected to a business capability, but without a Capabilities Based Plan as in above, can't really tell.

Screen Shot 2014-07-16 at 12.16.26 PM

So How Did We Get In This Situation?

Here's a biased opinion informed by my several decades of experience writing code and managing others who write code - we're missing the systems engineering paradigm in commercial software development. That is for software development of mission critical systems, and Enterprise IT is an example of mission critical systems.

Here's some posts:

The patradigm of Systems Engineering fills 1,000's pages and dozen's of books, but it is boiled down to this.

You need to know what DONE looks like in units of measure meaningful to the decision makers. Those units start with Measures of Effectiveness and Measures of Performance.

Each of those measures is probabilistic, driven by the underlying statistical processes of the system. These mean you must be able to estimate not only cost and schedule, but how that cost and schedule will deliver the needed system capabilities measured in MOE's and MOP's.

SE in One Page

Related articles Do It Right or Do It Twice Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Agile vs Waterfall: Introduction Lean Startup, Innovation, #NoEstimates, and Minimal Viable Features
Categories: Project Management

Agile and the Definition of Quality

“Quality begins on the inside... then works its way out.” -- Bob Moawad

Quality is value to someone.

Quality is relative.

Quality does not exist in a non-human vacuum.

Who is the person behind a statement about quality?

Who’s requirements count the most?

What are people willing to pay or do to have their requirements met?

Quality can be elusive if you don’t know how to find it, or you don’t know where to look.  Worse, even when you know where to look, you need to know how to manage the diversity of conflicting views.

On a good note, Agile practices and an Agile approach can help you surface and tackle quality in a tractable and pragmatic way.

In the book Agile Impressions, by “the grandfather of Agile Programming”, Jerry Weinberg shares insights and lessons learned around the relativity of quality and how to make decisions about quality more explicit and transparent.

Example of Conflicting Ideas About Software Quality

Here are some conflicting ideas about what constitutes software quality, according to Weinberg:

“Zero defects is high quality.”
“Lots of features is high quality.”
Elegant coding is high quality.”
“High performance is high quality.”
”Low development cost is high quality.”
“Rapid development is high quality.”
“User-friendliness is high quality.”

More Quality for One Person, May Mean Less for Another

There are always trade-offs.  It can be a game of robbing Peter to pay Paul.

Via Agile Impressions:

“Recognizing the relativity of quality often resolves the semantic dilemma. This is a monumental contribution, but it still does not resolve the political dilemma:  More quality for one person may mean less quality for another.”

The Relativity of Quality

Quality is relative.

Via Agile Impressions:

“The reason for my dilemma lies in the relativity of quality. As the MiniCozy story crisply illustrates, what is adequate quality to one person may be inadequate quality to another.”

Quality Does Not Exist in a Non-Human Vacuum

So many

Via Agile Impressions:

“If you examine various definitions of quality, you will always find this relativity. You may have to examine with care, though, for the relativity is often hidden, or at best, implicit.

In short, quality does not exist in a non-human vacuum, but every statement about quality is a statement about some person(s).  That statement may be explicit or implicit. Most often, the “who” is implicit, and statements about quality sound like something Moses brought down from Mount Sinai on a stone tablet.  That’s why so many discussions of software quality are unproductive: It’s my stone tablet versus your Golden Calf.”

Ask, Who is the Person Behind that Statement About Quality?

The way to have more productive conversations about quality is to find out who is the person behind a specific statement about quality.

Via Agile Impressions:

“When we encompass the relativity of quality, we have a tool to make those discussions more fruitful.  Each time somebody asserts a definition of software quality, we simply ask, “Who is the person behind that statement about quality.”

Quality Is Value To Some Person

Whose requirements count the most?

Via Agile Impressions:

“The political/emotional dimension of quality is made evident by a somewhat different definition of quality.  The idea of ‘requirements’ is a bit too innocent to be useful in this early stage, because it says nothing about whose requirements count the most. A more workable definition would be this:

‘Quality is value to some person.’

By ‘value,’ I mean, ‘What are people willing to pay (do) to have their requirements met.’ Suppose, for instance, that Terra were not my niece, but the niece of the president of the MiniCozy Software Company.  Knowing MiniCozy’s president’s reputation for impulsive emotional action, the project manager might have defined “quality” of the word processor differently.  In that case, Terra’s opinion would have been given high weight in the decision about which faults to repair.”

The Definition of “Quality” is Always Political and Emotional

Quality is a human thing.

Via Agile Impressions:

“In short, the definition of ‘quality’ is always political and emotional, because it always involves a series of decisions about whose opinions count, and how much they count relative to one another. Of course, much of the time these political/emotional decisions– like all important political/emotional decisions–are hidden from public view. Most of us software people like to appear rational. That’s why very few people appreciate the impact of this definition of quality on the Agile approaches.”

Agile Teams Can Help Make Decisions About Quality More Explicit Transparent

Open processes and transparency can help arrive at a better quality bar.

Via Agile Impressions:

“What makes our task even more difficult is that most of the time these decisions are hidden even from the conscious minds of the persons who make them.  That’s why one of the most important actions of an Agile team is bringing such decisions into consciousness, if not always into public awareness. And that’s why development teams working with an open process (like Agile) are more likely to arrive at a more sensible definition of quality than one developer working alone. To me, I don’t consider Agile any team with even one secret component.”

The "Customer" Must Represent All Significant Decisions of Quality

The quality of your product will be gated by the quality of your representation.

Via Agile Impressions:

“Customer support is another emphasis in Agile processes, and this definition of quality guides the selection of the ‘customers.’ To put it succinctly, the ‘ customer’ must actively represent all of the significant definitions of ‘quality.’ Any missing component of quality may very likely lead to a product that’s deficient in that aspect of quality.”

If You Don’t Have Suitable Representation of Views on Quality, You’re Not Agile

It’s faster and far more efficient to ignore people and get your software done.  But it’s far less effective.  Your amplify your effectiveness for addressing quality by involving the right people, in the right way, at the right time.  That’s how you change your quality game.

Via Agile Impressions:

“As a consultant to supposedly Agile teams, I always examine whether or not they have active participation of a suitable representation of diverse views of their product’s quality. If they tell me, “We can be more agile if we don’t have to bother satisfying so many people, then they may indeed by agile, but they’re definitely not Agile.”

I’ve learned a lot about quality over the years.  Many of Jerry Weinberg’s observations and insights match what I’ve experienced across various projects, products, and efforts.   The most important thing I’ve learned is how much value is in the eye of the beholder and the stakeholder and that quality is something that you directly impact by having the right views involved throughout the process.

Quality is not something you can bolt on or something that you can patch.

While you can certainly improve things, so much of quality starts up front with vision and views of the end in mind.

You might even say that quality is a learning process of realizing the end in mind.

For me, quality is a process of vision + rapid learning loops to iterate my way through the jungle of conflicting and competing views and viewpoints, while brining people along the journey.

Categories: Architecture, Programming

What About Cleaning Toilets?

NOOP.NL - Jurgen Appelo - Thu, 07/17/2014 - 16:00
Cleaning toilets

I often promote work-life fusion, quitting jobs that are not fulfilling, and seeking work that is a calling instead of just a career. But, I hear some people think, can this be true for everyone? Is there a great job, somewhere, for every person in the world?

What about cleaning toilets?

How can this work be fulfilling to anyone?

Well, that depends…

The post What About Cleaning Toilets? appeared first on NOOP.NL.

Categories: Project Management

Can I Be A Professional Mobile Developer? (iOS / Android)

Making the Complex Simple - John Sonmez - Thu, 07/17/2014 - 15:00

Yes. Yes, you can. At least I think so. In this video I talk about why.

The post Can I Be A Professional Mobile Developer? (iOS / Android) appeared first on Simple Programmer.

Categories: Programming

How Stand-up Meetings Go Wrong: Team Issues

Bad attitude!

Bad attitude!

The daily stand-up meeting is an easy Agile practice to adopt and an easy process to get wrong.  When an organization or a team gets stand-up meetings wrong the problems tend to stem from either a people or a process problem.  Each category can be broken down into a number of more specific problems, each with different symptoms and solutions. Today we’ll talk about people problems. People problems are really team problems. Teams are made up of the interactions between people pursuing a common goal.  Each person has his or her own motivations, goals and biases.  Because teams are made up of people, teams are complex and chaotic.  Stand-up meetings can be a window into structure and health of any team.  Some typical symptoms seen in stand-up meeting with engagement problems are passive aggressive behavior, poor stand-up attendance, tasking personnel and controlling behavior.

Passive aggressive behavior between individual members  This indirect hostility is sometimes seen as members exchange information during the meeting.  The scrum master/coach should work with the individuals to identify and rectify the behavior.  I generally feel that this type of behavior is difficult to address as a team or in a retrospective because there is often too much personal defensiveness.  If the problem cannot be solved at the team level get a line/HR manager involved, but do this only as a last resort.

Poor attendance  Assuming that there isn’t a scheduling problem, poor attendance reflects how much the team values the stand-up meeting.  If this is a problem, the scrum master/coach should schedule a retrospective to help the team uncover the root cause for the attendance problem.  Attendance problems are generally a reflection of how team members value each other.

Tasking meeting  Stand-ups in which a leader hands out tasks to the team show that the team (or a manager) has not embraced the core Agile principles of self-organized and self-managed teams. In this situation the team either can’t or won’t engage in managing the work.  Start addressing the problem with training and coaching, both at the IT management level and the team level, to drive home how the Agile principles should be practiced.  If an organization or team can’t stop tasking team members, longer-term organizational change is needed. Until that can be accomplished the primary value of Agile is out of reach.

Controlling behavior  Behavior in stand-up meetings often reflects behavior outside the meeting.  Teams generally have a leader, however when a person crosses over the line and becomes dominating, teams can lose the potential advantages of diverse voices. This type of behavior is most common when parts of team are at a power disadvantage. For example, contractors are often placed in subservient position if someone on the team controls their contract renewal.  When this issue is discovered, the scrum master/coach should begin with one-on-coaching change the behavior. Beginning with the specific team members in a problem makes sure no one feels blindsided (this is rarely a conscious behavior). Secondly, I find that after the team members are aware of the problem, it is helpful for the team to address the issue using retrospectives.

A good scrum master/coach needs to look for coachable moments to recognize and confront the problems. Where the issue is more systemic, techniques like retrospectives and training can be brought to bear. In the end everyone involved have to recognize the symptoms, but treat the problems.


Categories: Process Management

The New Roboto

Google Code Blog - Wed, 07/16/2014 - 18:00
By Christian Robertson, Android Visual Designer

Along with the Material Design guidelines we released a new version of the Roboto type family. A lot of things have changed as we tuned the font to work across more screen sizes and conditions, from watches to desktops, televisions to cars. It still keeps much of its character that made it successful for both phones and tablets, but almost every glyph has been tweaked and updated in some way.

We see Roboto as an evolving type family and plan to continue to change and update it as the system evolves. It used to be that a type family was designed once and then used without change for many years. Sometimes an updated version was released with a new name, sometimes by appending a "Neue" or "New". The old model for releasing metal typefaces doesn't make sense for an operating system that is constantly improving. As the system evolves over time, the type should evolve along with it.

The easiest way to identify the new version is to look for the R and K. They were some of the rowdier glyphs from version one and have been completely redrawn. Also check for the dots on the letter i or in the punctuation. We have rounded them out to make the types a little more friendly when you look at them closely. We also rounded out the sides of the upper case characters like O and C which makes the font feel less condensed even though it still has a high character count per line.

Some of the most significant changes are in the rhythm and spacing, especially for the caps. This isn't apparent as you look at individual glyphs, but makes for a better texture on the screen. Some of the more subtle fixes were to balance the weights between the caps and lowercase characters (the caps are slightly heavier in this version) and better correction for the distortions that occur in the obliqued italic characters.

Ultimately the purpose of a typeface is to serve the content and help people to understand it. We think that the new updates to Roboto along with the new Material Design guidelines will help it do more of just that.

Posted by Louis Gray, Googler
Categories: Programming

10 Program Busting Caching Mistakes

While Ten Caching Mistakes that Break your App by Omar Al Zabir is a few years old, it is still a great source of advice on using caches, especially on the differences between using a local in-memory cache and when using a distributed cache.

Here are the top 10 mistakes (summarized):
  1. Relying on a default serializer. Default serializers can use a lot of CPU, especially for complex types. Give some thought to the best serialization and deserialization method for your language and environment.
  2. Storing large objects in a single cache item. Because of serialization and deserialization costs, under concurrent load, frequent access to large object graphs can kill your server's CPU. Instead, break up the larger graph into smaller subgraphs and cache them separately. Retrieve only the smallest unit you need.
  3. Using cache to share objects between threads. Race conditions, when writes are involved, develop if parts of a program are accessing the same cached items simultaneously. Some sort of external locking mechanism is needed. 
  4. Assuming items will be in cache immediately after storing them. Never assume an item will be in a cache, even after it was just written, because a cache can flush items when memory gets tight. Code should always check for a null return value from a cache.
  5. Storing entire collection with nested objects. Storing an entire collection when you need to get a particular item results in poor performance because of the serialization overhead. Cache individual items separately so they can be retrieved separately. 
  6. Storing parent-child objects together and also separately. Sometimes an object will simultaneously be contained in two or more parent objects. To not have the same object stored in two different places in the cache store it on its own under its own key. The parent objects will then read the objects when access is needed.
  7. Caching Configuration settings. Store configuration data in a static variable that is local to your process. Accessing cached data is expensive so you want to avoid that cost when possible.
  8. Caching Live Objects that have open handle to stream, file, registry, or network. Don't cache objects the have references to resources like files, streams, memory, etc. When the cached item is removed from the cache those resources will not be deleted and system resources will leak. 
  9. Storing same item using multiple keys. It can be convenient to access an item by a key and an index number.  This can work when a cache is in-memory because the cache can contain a reference to the same object which means changes to the object will be seen through both access paths. When using a remote cache any updates won't be visible so the objects will get out of sync. 
  10. Not updating or deleting items in cache after updating or deleting them on persistent storage. Items in a remote cache are stored as a copy, so updating an object won't update the cache. The cache must specifically be updated for the changes to be seen by anyone else. With an in-memory cache changes to an object will be seen by everyone. Same for deletion. Deleting an object won't delete it from the cache. It's up to the program make sure cached items are deleted correctly.
Categories: Architecture

The Robotic Jockey

Software Requirements Blog - Seilevel.com - Wed, 07/16/2014 - 12:18
In the March 1945 issue of “Radio-Craft”, a bold vision was laid out for the future of horse racing: human jockeys should be replaced by motorized, radio-controlled “Robotic Jockeys”.   Taken from the same article, the author describes how these new jockeys would work: “The “jockey” would consist of a modern radio receiver, with outputs […]
Categories: Requirements