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

SE-Radio Episode 282: Donny Nadolny on Debugging Distributed Systems

Donny Nadolny of PagerDuty joins Robert Blumen to tell the story of debugging an issue that PagerDuty encountered when they set up a Zookeeper cluster that spanned across two geographically separated datacenters in different regions.  The debugging process took them through multiple levels of the stack starting with their application, the implementation of the Zookeeper […]
Categories: Programming

Hey, Join My New Project!

NOOP.NL - Jurgen Appelo - Tue, 02/14/2017 - 20:24

I am going to challenge you.

I want to see you do things you’ve never done before. I want you to learn, experiment, fail beautifully, and then try again. And I want to see you make progress in areas that few people in the world have explored.

I am talking about my new project.
You are welcome to join.

Why are you checking your Facebook or Twitter streams multiple times per day? Is it because you were sent to a social media workshop by your manager? Or because these companies are smartly targeting your intrinsic motivators?

What has caused millions of people to start running, exercising, and monitoring their calorie intakes? Was there a government campaign promoting healthier lifestyles? Or is it because thousands of apps, smartphones and wearables have made it a lot more fun?

What convinced me to switch from taxis to ridesharing, from radio stations to streaming music, and from workstations to tablets and notebooks? Is it because it’s part of someone else’s change program? Or because I wanted a more convenient work-life?

I’m sure you get my point.

People don’t change because they’re told to change. People change because smart companies make them want to change. It usually involves techniques borrowed from gamification, behavioral economics, and habitualization.

Consider a fitness tracker, for example. I run three times per week because the metrics of the fitness tracker on my smartphone have gamified the exercises so that I’m competing against myself. By showing me statistics, and comparing those with others, the tracker uses “nudges” borrowed from behavioral economics to influence my behaviors further. And by reinforcing the good behaviors with various triggers and rewards, the app has turned my regular exercises into habits.

Games, nudges, and habits.
That’s how people change.

We now live in a time where manuals, workshops, promotion campaigns, and change programs are not sufficient anymore to achieve organizational change. To really understand and influence people, we can now use smartphones, wearables, big data, artificial intelligence, and a healthy dose of applied psychology and sociology.

Do you find that fascinating?
Let’s try and improve organizations in a more modern way.

JOIN ME

The post Hey, Join My New Project! appeared first on NOOP.NL.

Categories: Project Management

New OnDemand Course - Scrum Overview

10x Software Development - Steve McConnell - Tue, 02/14/2017 - 18:23

Hello, Steve McConnell here. We are always updating our Construx OnDemand training, and I’m happy to announce a new course: Scrum Overview. Scrum enables software development teams to address complex adaptive problems, and in this course you’ll learn Scrum’s elements—its roles, events, and artifacts—as well as their purpose: how they’re all bound together to make Scrum hum. In short, you’ll learn what’s different about Scrum and what makes it so effective.

With the myriad Scrum courses available today, why would you take a course called Scrum Overview? If you’re a nontechnical stakeholder, such as an executive or sales and marketing staff or even a product owner, you might find value in getting an introduction to Scrum without diving into all the details, and the context that’s set in this course can very valuable. Even if you are a practitioner and you expect to get into the in’s and out’s of Scrum on a daily basis, it can useful to start with the context of Scrum so that you understand its full scope before diving into all those implementation details. Either way this can be a valuable introduction and overview of Scrum.

Your instructor in this course is Jenny Stuart. Jenny has been Vice President of Consulting at Construx for more than 10 years, and in that role she has overseen Construx’s work in implementing Scrum, and implementing Agile practices more generally, in organizations throughout North America and around the world. Jenny has worked effectively with individual contributors on Scrum teams, with Scrum Masters, and with executives who are supporting Scrum at the organizational level, and she has learned numerous lessons about how to support Scrum effectively by working at all those different levels. You’re in good hands with Jenny as the leader of this course.

  • Here’s the top-level outline for the course:
  • Introduction
  • The Scrum Framework
  • Scrum Roles
  • Requirements in Scrum
  • Agile Estimation
  • Plan a Sprint
  • Execute a Sprint
  • Wrap Up a Sprint
  • Adoption Pitfalls
  • Conclusion
If you want to go deeper with Scrum, follow this course with Construx OnDemand’s Scrum Boot Camp, which will teach you what you need to know to become certified in Scrum.

If you’re a Scrum Product Owner or want to become one, Product Owner Boot Camp drills down into the details you need to successfully plan releases, reflect stakeholder priorities, ensure the team builds the right product, and communicate with project stakeholders.

For more on developing requirements in Agile scenarios such as Scrum, see Agile Requirements Boot Camp, which teaches you how to use story mapping to define project scope, write user stories, size stories (agile estimation), and develop acceptance criteria for user stories.

Try Construx OnDemand for free today (no credit card required), and enjoy the course!

New OnDemand Course - Scrum Overview

10x Software Development - Steve McConnell - Tue, 02/14/2017 - 18:23

Hello, Steve McConnell here. We are always updating our Construx OnDemand training, and I’m happy to announce a new course: Scrum Overview. Scrum enables software development teams to address complex adaptive problems, and in this course you’ll learn Scrum’s elements—its roles, events, and artifacts—as well as their purpose: how they’re all bound together to make Scrum hum. In short, you’ll learn what’s different about Scrum and what makes it so effective.

With the myriad Scrum courses available today, why would you take a course called Scrum Overview? If you’re a nontechnical stakeholder, such as an executive or sales and marketing staff or even a product owner, you might find value in getting an introduction to Scrum without diving into all the details, and the context that’s set in this course can very valuable. Even if you are a practitioner and you expect to get into the in’s and out’s of Scrum on a daily basis, it can useful to start with the context of Scrum so that you understand its full scope before diving into all those implementation details. Either way this can be a valuable introduction and overview of Scrum.

Your instructor in this course is Jenny Stuart. Jenny has been Vice President of Consulting at Construx for more than 10 years, and in that role she has overseen Construx’s work in implementing Scrum, and implementing Agile practices more generally, in organizations throughout North America and around the world. Jenny has worked effectively with individual contributors on Scrum teams, with Scrum Masters, and with executives who are supporting Scrum at the organizational level, and she has learned numerous lessons about how to support Scrum effectively by working at all those different levels. You’re in good hands with Jenny as the leader of this course.

  • Here’s the top-level outline for the course:
  • Introduction
  • The Scrum Framework
  • Scrum Roles
  • Requirements in Scrum
  • Agile Estimation
  • Plan a Sprint
  • Execute a Sprint
  • Wrap Up a Sprint
  • Adoption Pitfalls
  • Conclusion
If you want to go deeper with Scrum, follow this course with Construx OnDemand’s Scrum Boot Camp, which will teach you what you need to know to become certified in Scrum.

If you’re a Scrum Product Owner or want to become one, Product Owner Boot Camp drills down into the details you need to successfully plan releases, reflect stakeholder priorities, ensure the team builds the right product, and communicate with project stakeholders.

For more on developing requirements in Agile scenarios such as Scrum, see Agile Requirements Boot Camp, which teaches you how to use story mapping to define project scope, write user stories, size stories (agile estimation), and develop acceptance criteria for user stories.

Try Construx OnDemand for free today (no credit card required), and enjoy the course!

Sponsored Post: Aerospike, GoCardless, Auth0, InnoGames, Contentful, Stream, Scalyr, VividCortex, MemSQL, InMemory.Net, Zohocorp

Who's Hiring?
  • GoCardless is building the payments network for the internet. We’re looking for DevOps Engineers to help scale our infrastructure so that the thousands of businesses using our service across Europe can take payments. You will be part of a small team that sets the direction of the GoCardless core stack. You will think through all the moving pieces and issues that can arise, and collaborate with every other team to drive engineering efforts in the company. Please apply here.

  • InnoGames is looking for Site Reliability Engineers. Do you not only want to play games, but help building them? Join InnoGames in Hamburg, one of the worldwide leading developers and publishers of online games. You are the kind of person who leaves systems in a better state than they were before. You want to hack on our internal tools based on django/python, as well as improving the stability of our 5000+ Debian VMs. Orchestration with Puppet is your passion and you would rather automate stuff than touch it twice. Relational Database Management Systems aren't a black hole for you? Then apply here!

  • Contentful is looking for a JavaScript BackEnd Engineer to join our team in their mission of getting new users - professional developers - started on our platform within the shortest time possible. We are a fun and diverse family of over 100 people from 35 nations with offices in Berlin and San Francisco, backed by top VCs (Benchmark, Trinity, Balderton, Point Nine), growing at an amazing pace. We are working on a content management developer platform that enables web and mobile developers to manage, integrate, and deliver digital content to any kind of device or service that can connect to an API. See job description.
Fun and Informative Events
  • DBTA Roundtable Webinar: Fast Data: The Key Ingredients to Real-Time Success. Thursday February 23, 2017 | 11:00 AM Pacific Time. Join Stephen Faig, Research Director Unisphere Research and DBTA, as he hosts a roundtable discussion covering new technologies that are coming to the forefront to facilitate real-time analytics, including in-memory platforms, self-service BI tools and all-flash storage arrays. Brian Bulkowski, CTO and Co-Founder of Aerospike, will be speaking along with presenters from Attunity and Hazelcast. Learn more and register.

  • Your event here!
Cool Products and Services
  • Working on a software product? Clubhouse is a project management tool that helps software teams plan, build, and deploy their products with ease. Try it free today or learn why thousands of teams use Clubhouse as a Trello alternative or JIRA alternative.

  • A note for .NET developers: You know the pain of troubleshooting errors with limited time, limited information, and limited tools. Log management, exception tracking, and monitoring solutions can help, but many of them treat the .NET platform as an afterthought. You should learn about Loupe...Loupe is a .NET logging and monitoring solution made for the .NET platform from day one. It helps you find and fix problems fast by tracking performance metrics, capturing errors in your .NET software, identifying which errors are causing the greatest impact, and pinpointing root causes. Learn more and try it free today.

  • Auth0 is the easiest way to add secure authentication to any app/website. With 40+ SDKs for most languages and frameworks (PHP, Java, .NET, Angular, Node, etc), you can integrate social, 2FA, SSO, and passwordless login in minutes. Sign up for a free 22 day trial. No credit card required. Get Started Now.

  • Build, scale and personalize your news feeds and activity streams with getstream.io. Try the API now in this 5 minute interactive tutorial. Stream is free up to 3 million feed updates so it's easy to get started. Client libraries are available for Node, Ruby, Python, PHP, Go, Java and .NET. Stream is currently also hiring Devops and Python/Go developers in Amsterdam. More than 400 companies rely on Stream for their production feed infrastructure, this includes apps with 30 million users. With your help we'd like to ad a few zeros to that number. Check out the job opening on AngelList.

  • Scalyr is a lightning-fast log management and operational data platform.  It's a tool (actually, multiple tools) that your entire team will love.  Get visibility into your production issues without juggling multiple tabs and different services -- all of your logs, server metrics and alerts are in your browser and at your fingertips. .  Loved and used by teams at Codecademy, ReturnPath, Grab, and InsideSales. Learn more today or see why Scalyr is a great alternative to Splunk.

  • InMemory.Net provides a Dot Net native in memory database for analysing large amounts of data. It runs natively on .Net, and provides a native .Net, COM & ODBC apis for integration. It also has an easy to use language for importing data, and supports standard SQL for querying data. http://InMemory.Net

  • VividCortex is a SaaS database monitoring product that provides the best way for organizations to improve their database performance, efficiency, and uptime. Currently supporting MySQL, PostgreSQL, Redis, MongoDB, and Amazon Aurora database types, it's a secure, cloud-hosted platform that eliminates businesses' most critical visibility gap. VividCortex uses patented algorithms to analyze and surface relevant insights, so users can proactively fix future performance problems before they impact customers.

  • MemSQL provides a distributed in-memory database for high value data. It's designed to handle extreme data ingest and store the data for real-time, streaming and historical analysis using SQL. MemSQL also cost effectively supports both application and ad-hoc queries concurrently across all data. Start a free 30 day trial here: http://www.memsql.com/

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

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

If any of these items interest you there's a full description of each sponsor below...

Categories: Architecture

Three Questions to Ask when Being Micromanaged

Mike Cohn's Blog - Tue, 02/14/2017 - 16:00

One of the foundational principles of agile and Scrum is a belief in the power of self-organizing teams. This makes a micromanaging boss, ScrumMaster or product owner a particularly difficult problem for agile teams.

I’ve found asking three questions helpful in dealing with micromanagers.

Who?

The first question is Who? Who is being micromanaged? If you are being micromanaged but the rest of the team is not, this tells you it is your own performance that someone is worried about. If so, you’ll need to improve your own performance and that stakeholder’s view of your performance.

But if your entire team is being micromanaged, the behavior is just part of who that stakeholder is.

To determine whether it’s just you or your entire team being micromanaged, spend a sprint or two noting what types of things draw the micromanager’s attention. Log all micromanaging activities so you can look back at the data and determine who is being micromanaged.

When?

A log of micromanagement activity will also help you answer the second question: When is the micromanaging occurring?

Does the stakeholder micromanage shortly before or after a meeting? For example, a product owner might leave their customer call every Tuesday feeling stressed and more inclined to micromanage. Or a Scrum Master might be prone to micromanage the day before the monthly meeting with the engineering VP.

Some people are more prone to micromanage at a specific time of day. A boss early in my career was particularly prone to micromanaging before his first cup of coffee.

Others may be more prone to micromanagement at specific times during an iteration. Perhaps the person you’re dealing with is most prone to micromanaging during the last few days of the iteration when he or she gets nervous about whether everything will get done. Again, log this type of information so you can later look for patterns.

I use a spreadsheet with the following columns:

Date: The actual date (e.g., March 8, 2017). This usually won’t help identify patterns but can be useful if you look back on the data and need to remember what might have been going on in the organization at the time.

Day of Week: Sometimes micromanaging occurs most frequently on certain days (e.g. Friday) so note the day of the week.

Day of the Sprint: To help see if micromanaging occurs most frequently at certain points within a sprint, note the number of days into the sprint when the micromanaging occurred. For example “Day 3” or perhaps “7 / 10” to indicate it occurred on day seven of a ten-day sprint.

Time: Note the time of day when the micromanaging occurred (e.g., 10:15 A.M.)

Who Was Being Micromanaged: Note whether it was you personally, the entire team, or perhaps a teammate being micromanaged.

What Was Being Micromanaged: Note the issue in this column.

Context: Note whether the micromanaging coincided with anything else occurring within the sprint, project or organization. Did it occur right before or after a meeting? Which meeting? What was occurring during the iteration overall?

Notes: Include anything additional worth remembering about the incident. You can see a sample in the following table.

 

Date

Day of
week

Day of
Sprint Time Micromanager Who? What? Context Notes March 8 Wed 6

10:30

Anne me Story about adding data sources    

Anne asked me for the 3rd time in two days how this was going.

March 8

Wed 6 2:15 Arie team Next week’s new client launch  

Arie emailed the full team to remind everyone how important the new client launch is

 

March 8
 

Thurs 6 9:28 Anne teammate  

Story about Salesforce integration

While en route to daily scrum, Anne asked me to tell Ashish

to see her sometime about the story he’s working on for her.  

Ashish has been providing her a daily update already as she requested.

 

Why?

After you’ve logged a couple of weeks of micromanaging activities, it’s time to ask the third question: Why is the micromanaging happening?

Scan your log looking for patterns. See if there are triggers that create the micromanagement. Perhaps your product owner micromanages you after her weekly meeting with her boss.

Perhaps your line manager is prone to micromanaging at the end of the month when he has to prepare a report for his boss.

Based on the patterns you see, try to identify conversations that may be worth having with whoever is micromanaging. You’re unlikely to get far by merely saying, “Please stop micromanaging.” Instead, talk to micromanagers in an attempt to learn what concerns them that they’re behaving as they are.

Once you’ve identified some of the triggers for micromanaging, it’s time to anticipate and eliminate those triggers.

Anticipate and Eliminate

If you can anticipate micromanaging behavior by noticing when it occurs, work to eliminate the trigger. Often you can do this by proactively providing information to the micromanager.

For example, if you know your product owner gets stressed and micromanages after a weekly meeting with her boss, schedule a meeting with your product owner ahead of that meeting. Be sure your product owner is well informed and prepared for her meeting.

Proactively provide information to stakeholders who are prone to micromanagement. Try to do it just in time so they have (and remember) the information in advance of whatever triggers them.

Avoid creating burdensome new processes for yourself. But you can assert control over a stakeholder (or boss) relationship by proactively providing information rather than waiting to be asked for it and then being forced to provide it on someone else’s schedule.

Some People Are Incurable

By following the advice here, you won’t always be able to eliminate micromanagement. Some stakeholders are incurable micromanagers. But the tips here will help you take greater control over most situations and generally make them more tolerable.

How Have You Handled a Micromanager?

What’s your worst story of being micromanaged? How did you handle the situation? Please leave your thoughts in the comments below.

 

Get Your Free Micromanagement Log

Start tracking to help eliminate micromanagement

Download Now!

Micromanagement Log cover

Azure Functions imperative bindings

Xebia Blog - Tue, 02/14/2017 - 13:09
The standard input and output bindings in Azure Functions are written in a declarative pattern using the function.json. When defining input and output declarative, you do not have the option to change some of the bindings properties like the name or make multiple outputs from one input. An imperative binding can do this for you. In

Created an open source VSTS build & release task for Azure Web App Virtual File System

Xebia Blog - Tue, 02/14/2017 - 08:15
I’ve created a new VSTS Build & Release task to help you interact with the (VFS) Virtual File System API (Part of KUDU API of your Azure Web App). Currently this task can only be used to delete specific files or directories from the web app during your build or release workflow. It will be

I’ve Had Enough

NOOP.NL - Jurgen Appelo - Mon, 02/13/2017 - 18:50

I can’t take it anymore.

I’ve had enough of people asking me how they can improve their team, while none of the team members are willing to run any experiments and learn from their failures.

I’ve had enough of organizations that want to scale with agile, while the change programs that managers roll out are still mainly about cutting costs and optimizing profits.

I’ve had enough of politicians promising change and making things better, while the policies of their parties are all about scaremongering and protectionism.

I firmly believe that most people are good. They usually mean well. But more often than not, group performance is abysmal. Progress stalls because teams, organizations, and political parties lack a systemic approach to purposeful evolution. I fear that, in most cases, the whole is less than the sum of the parts. In other words, great people, terrible systems.

Can we help improve those groups?

I’m sure we can. But history proves that writing books, running workshops, and organizing conferences are not enough to achieve sustainable improvement. And despite their heroic efforts, coaches and consultants often see their hard-earned results evaporate after yet another idiotic organizational system failure.

I am convinced that the solution is staring us straight in the eyes. The very reason that teams, organizations, and political systems perform badly is that the world is changing faster and faster. Have you ever seen the adoption rates of smartphones, social networks, or streaming media? Did you see how fast people are learning to use wearables and robots?

Anyone who claims that “people resist change” is just flaunting his or her incompetence.

They key to improving collaboration and performance across teams, organizations and other groups is understanding how some human behaviors are adopted at a rate that is similar to a global epidemic. If you have a good idea, and people aren’t picking it up, it doesn’t mean that they resist the change. It also doesn’t mean that your idea is wrong. It just means that there is no platform enabling the idea to go viral.

I’ve had enough of good people wasting their time in bad teams and organizations. I’ve had enough of fantastic books, workshops, conferences, coaches, and consultants achieving only temporary performance fixes. We need a platform that allows good ideas to spread across teams and organizations at Internet-speed. And like the adoption rates of new technologies, we need that platform to make any behavioral changes sustainable.

I want the whole to be more than the sum of the parts. There should be a platform that helps people grow awesome systems.

Do you want to build that platform with me?

JOIN ME

The post I’ve Had Enough appeared first on NOOP.NL.

Categories: Project Management

Part 3 of Thinking Serverless —  Dealing with Data and Workflow Issues

This is a guest repost by Ken Fromm, a 3x tech co-founder — Vivid Studios, Loomia, and Iron.io. Here's Part 1 and 2

This post is the third of a four-part series of that will dive into developing applications in a serverless way. These insights are derived from several years working with hundreds of developers while they built and operated serverless applications and functions. The platform was the serverless platform from Iron.io but these lessons can also apply to AWS LambdaGoogle Cloud FunctionsAzure Functions, and IBM’s OpenWhisk project.

Serverless Processing — Data Diagram

Thinking Serverless! The Data
Categories: Architecture

Discomfort as a Tool for Change

Google Testing Blog - Mon, 02/13/2017 - 17:53
by Dave Gladfelter (SETI, Google Drive)
IntroductionThe SETI (Software Engineer, Tools and Infrastructure) role at Google is a strange one in that there's no obvious reason why it should exist. The SWEs (Software Engineers) on a project understand its problems best, and understanding a problem is most of the way to fixing it. How can SETIs bring unique value to a project when SWEs have more on-the-ground experience with their impediments?

The answer is scope. A SWE is rewarded for being an expert in their particular area and domain and is highly motivated to make optimizations to their carved-out space. SETIs (and Test Engineers and EngProdin general) identify and solve product-wide problems.

Product-wide problems frequently arise because local optimizations don't necessarily add up to product-wide optimizations. The reason may be the limits of attention, blind spots, or mis-aligned incentives, but a group of SWEs each optimizing for their own sub-projects will not achieve product-wide maxima.

Often SETIs and Test Engineers (TEs) know what behavior they'd like to see, such as more integration tests. We may even have management's ear and convince them to mandate such tests. However, in the absence of incentives, it's unlikely that the decisions SWEs make in response to such mandates will add up to the behavior we desire. Mandates around methods/practices are often ineffective. For example, a mandate of documentation for each public method on an interface often results in "method foo does foo."

The best way to create product-wide efficiencies is to change the way the team or process works in ways that will (initially) be uncomfortable for the engineering team, but that pays dividends that can't be achieved any other way. SETIs and TEs must work to identify the blind spots and negative interactions between engineering teams and change the environment in ways that align engineering teams' incentives. When properly incentivized, SWEs will make optimal decisions enhanced by product-wide vision rather than micro-management.
Common Product-Wide ProblemsHard-to-use APIsOne common example of local optimizations resulting in cross-team de-optimization is documentation and ease-of-use of internal APIs. The team that implements an internal API is not rewarded for making it easy to use except in the most oblique ways. Clients are compelled to use the internal APIs provided to them, so the API owner has a monopoly and will set the price of using it at "you must read all the code and debug it yourself" in the absence of incentives or (rare) heroes.
Big, slow releasesAnother example is large and slow releases. Without EngProd help or external pressure, teams will gravitate to the slowest, biggest release possible.

This makes sense from the position of any individual SWE: releases are painful, you have to ensure that there are no UI and API regressions, watch traffic and error rates for some time, and re-learn and use tools and processes that are complex and specific to releases.

Multiple teams will naturally gravitate to having one big release so that all of these costs can be bundled into one operation for "efficiency." The result is that engineers don't get feedback on features for weeks and versioning of APIs and data stores is ignored (since all the parts of the system are bundled together into one big release). This greatly slows down developer and feature velocity and greatly increases risks of cascading failures when the release fails.
How EngProd fixes product-wide problemsSETIs can nibble around the edges of these kinds of problems by writing tools and automation. TEs can create easy-to-use test environments that facilitate isolating and debugging faults in integration and ambiguities in APIs. We can use fancy technologies to sample live traffic and ensure that new versions of systems behave the same as previous versions. We can review design docs to ensure that they have an appropriate test plan. Often these actions do have real value. However, these are not the best way to align incentives to create a product-wide solution. Facilitating engineering teams' fruitful collaboration (and dis-incentivizing negative interactions) gives EngProd a multiplier that is hard to achieve with only tooling and automation.

Heroes are few and far between so we must turn to incentives, which is where discomfort comes in. Continuity is comfortable and change is painful. EngProd looks at how to change the problem so that teams are incentivized to work together fruitfully and disincentivized (discomforted) to pursue local optimizations exclusively.

So how does EngProd align incentives? Certainly there is a place for optimizing for optimal behaviors, such as easy-to-use integration environments. However, incentivizing optimal behaviors via negative feedback should not be overlooked. Each problem is different, so let's look at how to address the two examples above:
Incentivizing easy-to-use APIsEngineers will make the things they're incentivized to make. For APIs, make teams incentivized to provide integration help in the form of fakes. EngProd works with team leads to ensure there are explicit objectives to provide Fakes for their APIs as part of the rollout.

Fakesare as-simple-as-possible implementations of a service that still can be used to do pre-submit testing of client interactions with the system. They don't replace integration tests, but they reduce the likelihood of finding errors in subsequent integration test runs by an order of magnitude.
Furthermore, have some subset of the same client-owned and server-owned tests run against the fakes (for quick presubmit testing) as well as the real implementation (for continuous integration testing) and work with management to make it the responsibility of the Fake owner to debug any discrepancies for either the client- or the server-owned tests.

This reverses the pain! API owners, who are in a position to make APIs better, are now the ones experiencing negative incentives when APIs are not easy to use. Previously, when clients felt the pain, they had no recourse other than to file easily-ignored bugs ("Closed: working as intended") or contribute changes to the API owners' codebase, hurting their own performance with distractions.

This will incentivize API owners to design APIs to be as simple as possible with as few side-effects as possible, and to provide high-quality fakes that make it easy for clients to integrate with the API. Some teams will certainly not like this change at first, but I have seen API teams come to the realization that this is the best choice for the larger effort and implement these practices despite their cost to the team in the short run.

Helping management set engineering team objectives may not seem like a typical SETI responsibility, but although management is responsible for setting performance incentives and objectives, they are not well-positioned to understand how the low-level decisions of different teams create harmful interactions and lower cross-team performance, so they need SETI and TE guidance to create an environment that encourages optimal behaviors.
Fast, small releasesBeing forced to release more frequently than is required by feature deployment requirements has many beneficial side-effects that make release velocity a goal unto itself. SETIs and TEs faced with big, slow releases work with management to mandate a move to a set of smaller, more frequent releases. As release velocity is ratcheted up, negative behaviours such as too much manual testing or too much internal coupling become more painful, and many optimal behaviors are incentivized.
Less coupling between systemsWhen software is released together, it is easy to treat the seams between different components as implementation details. Resulting systems becoming so intertwined (coupled) that responsibilities between them are completely and randomly mixed and their interactions are too complex for any one person to understand. When two components are released separately and at different times, different versions of them must be compatible with one another. Engineers who were previously complacent about this fragility will become fearful of failed releases due to implicit contract changes. They will change their behavior in beneficial ways such as defining the contract between components explicitly and creating regression testing for it. The result is a system composed of robust, self-contained, more easily understood components.
Better/More automated testingManual testing becomes more painful as release velocity is ramped up. This will incentivize automated regression, UI and performance tests. This makes the team more agile and able to catch defects sooner and more cheaply.
Faster feedbackWhen incremental feature changes can be released to dogfood or other beta channels more frequently, user interaction designers and product managers get much faster feedback about what paths lead to better user engagement and experience than in big, slow releases where an entire feature is deployed simultaneously. This results in a better product.
ConclusionThe SETIs and TEs optimize interactions between teams and create fixes for product-wide, cross-team problems in order to improve engineering productivity and velocity. There are many worthwhile projects that EngProd can do using broad knowledge of the system and expertise in refactoring, automation and testing, such as creating test fixtures that enable continuous integration testing or identifying and combining duplicative tests or tools.

That said, the biggest problem that EngProd is positioned to solve is to break the chain of local optimizations resulting in cross-team de-optimizations. To that end, discomfort is a tool that can incentivize engineers to find solutions that are optimal for the entire product. We should look for and advocate for these transformative changes.
Categories: Testing & QA

Discomfort as a Tool for Change

Google Testing Blog - Mon, 02/13/2017 - 17:53
by Dave Gladfelter (SETI, Google Drive)
IntroductionThe SETI (Software Engineer, Tools and Infrastructure) role at Google is a strange one in that there's no obvious reason why it should exist. The SWEs (Software Engineers) on a project understand its problems best, and understanding a problem is most of the way to fixing it. How can SETIs bring unique value to a project when SWEs have more on-the-ground experience with their impediments?

The answer is scope. A SWE is rewarded for being an expert in their particular area and domain and is highly motivated to make optimizations to their carved-out space. SETIs (and Test Engineers and EngProdin general) identify and solve product-wide problems.

Product-wide problems frequently arise because local optimizations don't necessarily add up to product-wide optimizations. The reason may be the limits of attention, blind spots, or mis-aligned incentives, but a group of SWEs each optimizing for their own sub-projects will not achieve product-wide maxima.

Often SETIs and Test Engineers (TEs) know what behavior they'd like to see, such as more integration tests. We may even have management's ear and convince them to mandate such tests. However, in the absence of incentives, it's unlikely that the decisions SWEs make in response to such mandates will add up to the behavior we desire. Mandates around methods/practices are often ineffective. For example, a mandate of documentation for each public method on an interface often results in "method foo does foo."

The best way to create product-wide efficiencies is to change the way the team or process works in ways that will (initially) be uncomfortable for the engineering team, but that pays dividends that can't be achieved any other way. SETIs and TEs must work to identify the blind spots and negative interactions between engineering teams and change the environment in ways that align engineering teams' incentives. When properly incentivized, SWEs will make optimal decisions enhanced by product-wide vision rather than micro-management.
Common Product-Wide ProblemsHard-to-use APIsOne common example of local optimizations resulting in cross-team de-optimization is documentation and ease-of-use of internal APIs. The team that implements an internal API is not rewarded for making it easy to use except in the most oblique ways. Clients are compelled to use the internal APIs provided to them, so the API owner has a monopoly and will set the price of using it at "you must read all the code and debug it yourself" in the absence of incentives or (rare) heroes.
Big, slow releasesAnother example is large and slow releases. Without EngProd help or external pressure, teams will gravitate to the slowest, biggest release possible.

This makes sense from the position of any individual SWE: releases are painful, you have to ensure that there are no UI and API regressions, watch traffic and error rates for some time, and re-learn and use tools and processes that are complex and specific to releases.

Multiple teams will naturally gravitate to having one big release so that all of these costs can be bundled into one operation for "efficiency." The result is that engineers don't get feedback on features for weeks and versioning of APIs and data stores is ignored (since all the parts of the system are bundled together into one big release). This greatly slows down developer and feature velocity and greatly increases risks of cascading failures when the release fails.
How EngProd fixes product-wide problemsSETIs can nibble around the edges of these kinds of problems by writing tools and automation. TEs can create easy-to-use test environments that facilitate isolating and debugging faults in integration and ambiguities in APIs. We can use fancy technologies to sample live traffic and ensure that new versions of systems behave the same as previous versions. We can review design docs to ensure that they have an appropriate test plan. Often these actions do have real value. However, these are not the best way to align incentives to create a product-wide solution. Facilitating engineering teams' fruitful collaboration (and dis-incentivizing negative interactions) gives EngProd a multiplier that is hard to achieve with only tooling and automation.

Heroes are few and far between so we must turn to incentives, which is where discomfort comes in. Continuity is comfortable and change is painful. EngProd looks at how to change the problem so that teams are incentivized to work together fruitfully and disincentivized (discomforted) to pursue local optimizations exclusively.

So how does EngProd align incentives? Certainly there is a place for optimizing for optimal behaviors, such as easy-to-use integration environments. However, incentivizing optimal behaviors via negative feedback should not be overlooked. Each problem is different, so let's look at how to address the two examples above:
Incentivizing easy-to-use APIsEngineers will make the things they're incentivized to make. For APIs, make teams incentivized to provide integration help in the form of fakes. EngProd works with team leads to ensure there are explicit objectives to provide Fakes for their APIs as part of the rollout.

Fakesare as-simple-as-possible implementations of a service that still can be used to do pre-submit testing of client interactions with the system. They don't replace integration tests, but they reduce the likelihood of finding errors in subsequent integration test runs by an order of magnitude.
Furthermore, have some subset of the same client-owned and server-owned tests run against the fakes (for quick presubmit testing) as well as the real implementation (for continuous integration testing) and work with management to make it the responsibility of the Fake owner to debug any discrepancies for either the client- or the server-owned tests.

This reverses the pain! API owners, who are in a position to make APIs better, are now the ones experiencing negative incentives when APIs are not easy to use. Previously, when clients felt the pain, they had no recourse other than to file easily-ignored bugs ("Closed: working as intended") or contribute changes to the API owners' codebase, hurting their own performance with distractions.

This will incentivize API owners to design APIs to be as simple as possible with as few side-effects as possible, and to provide high-quality fakes that make it easy for clients to integrate with the API. Some teams will certainly not like this change at first, but I have seen API teams come to the realization that this is the best choice for the larger effort and implement these practices despite their cost to the team in the short run.

Helping management set engineering team objectives may not seem like a typical SETI responsibility, but although management is responsible for setting performance incentives and objectives, they are not well-positioned to understand how the low-level decisions of different teams create harmful interactions and lower cross-team performance, so they need SETI and TE guidance to create an environment that encourages optimal behaviors.
Fast, small releasesBeing forced to release more frequently than is required by feature deployment requirements has many beneficial side-effects that make release velocity a goal unto itself. SETIs and TEs faced with big, slow releases work with management to mandate a move to a set of smaller, more frequent releases. As release velocity is ratcheted up, negative behaviours such as too much manual testing or too much internal coupling become more painful, and many optimal behaviors are incentivized.
Less coupling between systemsWhen software is released together, it is easy to treat the seams between different components as implementation details. Resulting systems becoming so intertwined (coupled) that responsibilities between them are completely and randomly mixed and their interactions are too complex for any one person to understand. When two components are released separately and at different times, different versions of them must be compatible with one another. Engineers who were previously complacent about this fragility will become fearful of failed releases due to implicit contract changes. They will change their behavior in beneficial ways such as defining the contract between components explicitly and creating regression testing for it. The result is a system composed of robust, self-contained, more easily understood components.
Better/More automated testingManual testing becomes more painful as release velocity is ramped up. This will incentivize automated regression, UI and performance tests. This makes the team more agile and able to catch defects sooner and more cheaply.
Faster feedbackWhen incremental feature changes can be released to dogfood or other beta channels more frequently, user interaction designers and product managers get much faster feedback about what paths lead to better user engagement and experience than in big, slow releases where an entire feature is deployed simultaneously. This results in a better product.
ConclusionThe SETIs and TEs optimize interactions between teams and create fixes for product-wide, cross-team problems in order to improve engineering productivity and velocity. There are many worthwhile projects that EngProd can do using broad knowledge of the system and expertise in refactoring, automation and testing, such as creating test fixtures that enable continuous integration testing or identifying and combining duplicative tests or tools.

That said, the biggest problem that EngProd is positioned to solve is to break the chain of local optimizations resulting in cross-team de-optimizations. To that end, discomfort is a tool that can incentivize engineers to find solutions that are optimal for the entire product. We should look for and advocate for these transformative changes.
Categories: Testing & QA

Installing a VSTS Build agent on Mac OSX

Xebia Blog - Mon, 02/13/2017 - 16:36
Today I needed to install the VSTS Build Agent on a Mac Mini in the office so we can build the IPhone App. The great part of the new build infrastructure in VSTS is that it is Cross Platform and we CAN do that. Just download the agent and run the command provided in the interface.

ReactJS/Material-UI: Cannot resolve module ‘material-ui/lib/’

Mark Needham - Sun, 02/12/2017 - 23:43

I’ve been playing around with ReactJS and the Material-UI library over the weekend and ran into this error while trying to follow one of the example from the demo application:

ERROR in ./src/app/modules/Foo.js
Module not found: Error: Cannot resolve module 'material-ui/lib/Subheader' in /Users/markneedham/neo/reactjs-test/src/app/modules
 @ ./src/app/modules/Foo.js 13:17-53
webpack: Failed to compile.

This was the component code:

import React from 'react'
import Subheader from 'material-ui/lib/Subheader'

export default React.createClass({
  render() {
    return 
    Some Text
    
  }
})

which is then rendered like this:

import Foo from './modules/Foo'
render(Foo, document.getElementById("app"))

I came across this post on Stack Overflow which seemed to describe a similar issue and led me to realise that I was actually on the wrong version of the documentation. I’m using version 0.16.7 but the demo I copied from is for version 0.15.0-alpha.1!

This is the component code that we actually want:

import React from 'react'
import Subheader from 'material-ui/Subheader'

export default React.createClass({
  render() {
    return 
    Some Text
    
  }
})

And that’s all I had to change. There are several other components that you’ll see the same error for and it looks like the change was made between the 0.14.x and 0.15.x series of the library.

The post ReactJS/Material-UI: Cannot resolve module ‘material-ui/lib/’ appeared first on Mark Needham.

Categories: Programming

SPaMCAST 430 – Project Owner, The Complicated Role, The Thinker, Constraints

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 430  features an essay on product owners.  The product owner role is nuanced, always complicated and sometimes hard.  The essay will help you sort things out.  

Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment we talk about Chapter 15, Understanding the Impact of a Constraint.  In our discussion Steve schooled me a bit on constraints.

Gene Hughson brings his  Form Follows Function Blog (the same Gene, that Ryan Ripley called out on last week’s cast) to the cast this week to discuss the third in his series on leadership.  This week we discussed the antipattern Gene calls The Thinker.  Might sound good, but it isn’t.

Have you checked out Agile for Humans? If not please do.  If you are an Agile for Humans listener visiting the Software Process and Measurement Cast for the first time, WELCOME. I hope you subscribe and make us part of your weekly ritual.

Re-Read Saturday News

This week  we tackle Chapter 3 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along). In Chapter 3 Dweck provides a deep dive into how mindsets affect learning and teaching.  The impact of mindsets on how we learn or how we teach is useful knowledge for anyone involved in coaching or transformation.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of someone pursuing an organizational transformation and also how to use the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

In the Software Process and Measurement Cast we talk with Andrew Neitlich on leadership.  We discussed whether leadership can be learned and if tech leadership is different than other kinds of leadership.  Leadership is a core requirement for making Agile effective!

Shameless Ad for my book!

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


Categories: Process Management

SPaMCAST 430 - Product Owner, The Complicated Role, The Thinker, Constraints

Software Process and Measurement Cast - Sun, 02/12/2017 - 23:00

The Software Process and Measurement Cast 430  features an essay on product owners.  The product owner role is nuanced, always complicated and sometimes hard.  The essay will help you sort things out.  

Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment we talk about Chapter 15, Understanding the Impact of a Constraint.  In our discussion Steve schooled me a bit on constraints.

Gene Hughson brings his  Form Follows Function Blog (the same Gene, that Ryan Ripley called out on last week’s cast) to the cast this week to discuss the third in his series on leadership.  This week we discussed the antipattern Gene calls The Thinker.  Might sound good, but it isn’t.

Have you checked out Agile for Humans? If not please do.  If you are an Agile for Humans listener visiting the Software Process and Measurement Cast for the first time, WELCOME. I hope you subscribe and make us part of your weekly ritual.

Re-Read Saturday News

This week  we tackle Chapter 3 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along). In Chapter 3 Dweck provides a deep dive into how mindsets affect learning and teaching.  The impact of mindsets on how we learn or how we teach is useful knowledge for anyone involved in coaching or transformation.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of someone pursuing an organizational transformation and also how to use the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

In the Software Process and Measurement Cast we talk with Andrew Neitlich on leadership.  We discussed whether leadership can be learned and if tech leadership is different than other kinds of leadership.  Leadership is a core requirement for making Agile effective!

Shameless Ad for my book!

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

Categories: Process Management

Force uninstall Visual Studio 2017 Release candidates

Xebia Blog - Sun, 02/12/2017 - 11:56
If you, like me, are stuck trying to upgrade Visual Studio 2017, then you may only get unblocked by removing everything and starting afresh. Since Visual Studio 2017 is still in Release Candidate and not final, this is something we may have to deal with from time to time. But when the "uninstall" button in

Add :8080 to your TFS 2017 bindings after upgrading to SSL

Xebia Blog - Sun, 02/12/2017 - 11:40
Because TFS 2017 allows authentication with Personal Access Tokens (PAT) it's recommended to upgrade to SSL if you were still on port 80. The installer will even help with the configuration and can add a redirect from port :80 to :443. It doesn't add a a redirect from port :8080 though, so your users may

Mindset: The New Psychology of Success: Re-Read Week 3, Chapter 3 – The Truth About Ability and Accomplishment

Mindset Book Cover

Today we tackle Chapter 3 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along). In Chapter 3 Dweck provides a view into how different mindsets impacts how we learn and teach school and other learning scenarios.  The impact of mindsets can be wide and long lasting.

I have looked at a lot of resumes and talked to a lot of job applicants over my career and as a consultant, the tables are often turned on me in most sales calls. In these intimate dances, both parties are assessing the others abilities and accomplishments. During this assessment, we are making judgments of whether someone (or some organization) can satisfy our needs now and often whether they can grow to meet future needs. Perceptions about abilities and accomplishments color our thinking and our actions in many situations and in many ways.

Dweck opens the chapter with a discussion of how the two mindsets affect teachers and students in schools. Conceiving of a school setting might be difficult for a business person, therefore it would be easy to write off this chapter as not relevant. It is relevant, first as leaders we need to understand the long-term effect mindsets have on the people that are in our organization and secondly, the impact of mindsets can have on training and education that is delivered inside the organization. If you go no further and don’t read the chapter, the punchline in this chapter can be summarized as, people with fixed mindset will find excuses and rationalize any perceived failures while those with a growth mindset will tend to double-down and work harder as work gets more difficult.

As we have seen in other scenarios described in earlier chapters in Mindset, those with a fixed mindset spend a lot of time and effort in order to protect their ego and to avoid the perception of failure. The need to spend time on ego protection saps time and focus from all other endeavors. As another example, Dweck describes the impact of different mindsets on how individuals study. A person with a fixed mindset will tend to read and re-read their notes and the assigned course reading. A fairly classic approach to studying (I have used this method myself). Alternately, someone with a growth mindset will reformulate notes, look for themes in the material and leverage outside. Personally, reflecting on my studying performance, I used both methods on different topics, the difference being interest and passion. Dweck suggests that the difference is that the person with a growing mindset synthesizes the information so they can use it outside of the classroom rather than to take the test. Reflect on the people you talked to the last time you were in school or other form of educational environment which included a test. Can you remember hearing people complaining after a test that the question(s) asked weren’t exactly what the teacher or professor talked about in class?  I can and that is often a marker for a fixed mindset.

Dweck uses several other scenarios set in academic settings in the chapter to illuminate the central premise that people with a fixed mindset focus on protecting their ego while those with a growth mindset focus on learning and new challenges which improve motivation (and value to the organization).

The explicit, very bipolar, view of mindsets must be tempered with the understanding that everyone can change. Much of the chapter’s examples present how the student/teacher relationship influences whether a growth or fixed mindset is adopted.  One example presented by Dweck that resonated with me was that teachers who preached a growth mindset got different outcomes in the classroom. Children that started in the lower performance groups ended up in the higher groups by the end of the year. Expectations help frame how we treat people. Early in my eldest daughter’s scholastic career my wife and I changed her school because there was no expectation from some teachers that they needed to challenge her (it did not help that one teacher taught that dinosaurs and cavemen lived at the same time – in science class).  Expectations also work in the in the business environment (consider listening to the interview with David Marquet, author of Turn the Ship Around! On SPaMCAST xxx and xxx for more examples).

Expectations, effort, and struggle are key to growing capabilities and reflect a growth mindset. Giving up because something does not come naturally because you are not a prodigy, is a sign of a fixed mindset.

Expectations and the feedback generated by those expectations can be a double-edged sword. Praise for ability tends to foster more of the need for ego protection while expectations and praise for effort tend to elicit more effort (this supports the idea that mindsets can evolve). Dweck points out a study that found that when praise centered on ability nearly 40% lied about their results.

In this chapter, Dweck uses school and other learning examples. A growth mindset allows people to develop their minds fully versus a fixed mindset which is bound by the boundaries that they adopt. The chapter culminates with a set of questions to grow your mindset. For example, one question is, “Are there situations where you get stupid — where you disengage your intelligence?” The exercise is to consider those scenarios and think about how you can learn and improvement.

Chapter 3 – From a Coach’s Perspective

Transforming an organization (whatever size) requires growth. During an Agile transformation, people often need change how they work and interact with others around them.  This kind of a change can require people expand their capabilities, in the vernacular of the book, to shift mindsets. Instead of address individuals, a transformation coach often needs to focus on shifting the bias of the organization towards a growth mindset. Shifting the organization’s mindset bias towards growth will help to erode negative stereotypes and labels which will slow change.

Transforming a team can be approached more intimately. The coach and other leaders can create an environment and set expectations to reframe how people are treated. Setting and reinforcing a growth mindset will erode the silos that keep individuals from growing. Over the years as a leader, I have recognized that almost everyone has the ability to grow when given the chance. Coach have to help shape the environment and the language being used to in order to erase boundaries that limit achievement.

Previous Entries of the re-read of Mindset:

 


Categories: Process Management

Meet the 20 finalists of the Google Play Indie Games Contest in Europe

Android Developers Blog - Sat, 02/11/2017 - 02:55
Posted by Matteo Vallone, Google Play Games Business Development

Back in November, we launched the Google Play Indie Games Contest for developers from 15 European countries, to celebrate the passion and innovation of the indie community in the region. The contest will reward the winners with exposure to industry experts and players worldwide, as well as other prizes that will showcase their art and help them grow their business on Android and Google Play.

Thank you to the nearly 1000 of you who submitted high quality games in all types of genres! Your creativity, enthusiasm and dedication have once again impressed us and inspired us. We had a very fun time testing and judging the games based on fun, innovation, design excellence and technical and production quality, and it was challenging to select only 20 finalists:

Meet the 20 finalists
(In alphabetical order)

Blind Drive
(coming soon)

Lo-Fi People
Israel Causality
(coming soon)

Loju
United Kingdom
Crap! I'm Broke: Out of Pocket
Arcane Circus Netherlands
Egz

Lonely Woof
France
Ellipsis

Salmi GmbH Germany


Gladiabots


GFX47
France
Happy Hop: Kawaii Jump

Platonic Games
Spain
Hidden Folks (coming soon)

Adriaan de Jongh Netherlands Lichtspeer
(coming soon)

Lichthund
Poland Lost in Harmony
Digixart

Entertainment France


Mr Future Ninja (coming soon)

Huijaus Studios
Finland Paper Wings


Fil Games
Turkey PinOut


Mediocre
Sweden
Power Hover


Oddrok
Finland
Reigns

Nerial
United Kingdom
Rusty Lake: Roots

Rusty Lake Netherlands
Samorost 3

Amanita Design Czech Republic
The Battle of Polytopia
Midjiwan AB Sweden


twofold inc.

Grapefrukt games Sweden
Unworded (coming soon)

Bento Studio France

Check out the prizes

All the 20 finalists are getting:
  • The opportunity to exhibit and showcase their game at the final event held at the Saatchi Gallery in London, on 16th February 2017.
  • Promotion of their game on a London billboard for one month.
  • Two tickets to attend a 2017 Playtime event. This is an invitation-only event for top apps and games developers on Google Play.
  • One Pixel XL smartphone.
At the event at Saatchi, the finalists will also have a chance to make it to the next rounds and win additional prizes, including:
  • YouTube influencer campaigns worth up to 100,000 EUR.
  • Premium placements on Google Play.
  • Tickets to Google I/O 2017 and other top industry events.
  • Promotions on our channels.
  • Special prizes for the best Unity game.
  • And more!

Come support them at the final event

At the final event attendees will have a say on which 10 of these finalists will get to pitch their games to the jury, who will decide on the final contest winners who will receive the top prizes.

Register now to join us in London, meet the developers, check out their great games, vote for your favourites, and have fun with various industry experts and indie developers.



A big thank you again to everyone who entered and congratulations to the finalists. We look forward to seeing you at the Saatchi Gallery in London on 16th February.
Categories: Programming