The databinding for android has been one of the confusing frameworks to get started with. Granted the first thing I wanted to accomplish was databinding in a fragment and the examples really didn't show how that works. Anyway, let's get started 


Make a new project with an activity and a fragment and then update your gradle files to be similar to below. Certain versioning doesn't matter the primary thing you need is the build gradle to be above 1.2 and having the data binder dependency included. 

Project build.gradle 

buildscript {
    repositories {
    dependencies {
        classpath ''
        classpath ""

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files

allprojects {
    repositories {

In your app build gradle the key components are the apply plugin's listed below. I do believe you need a high enough build tool version, the 23 rc3 worked for me, feel free to experiment on what works for you. 

App Build Gradle

apply plugin: ''
apply plugin: ''

android {
    compileSdkVersion 22
    buildToolsVersion "23 rc3"

    defaultConfig {
        applicationId "com.darxstudios.databind.example"
        minSdkVersion 18
        targetSdkVersion 22
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner ""
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), ''
    // Ensure there is no packaging conflicts
    packagingOptions {
        exclude 'META-INF/LICENSE'
        exclude 'META-INF/NOTICE'
        exclude 'META-INF/DEPENDENCIES'
        exclude 'META-INF/LICENSE.txt'
        exclude 'META-INF/NOTICE.txt'
        exclude 'LICENSE.txt'

dependencies {
    // App Dependencies
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile ''

    //Testing Dependencies
    androidTestCompile ''
    // Set this dependency to use JUnit 4 rules
    androidTestCompile ''
    // Set this dependency to build and run Espresso tests
    androidTestCompile ''


Now that you have that setup before we start looking into adding the databinding to the fragment let's setup a model object that we want to use as our primary binding class. Let's call it User 

package com.darxstudios.databind.example;

import android.databinding.BaseObservable;
import android.databinding.Bindable;

public class User extends BaseObservable  {

    private String firstName;
    private String lastName;

    public String getFirstName() {
        return firstName;

    public void setFirstName(String firstName) {

        this.firstName = firstName;

    public String getLastName() {
        return lastName;


    public void setLastName(String lastName) {
        this.lastName = lastName;


In order to have your object hooked up to the view you need your object to extend BaseObservable. 

Just a note, you can also use implement's Observable instead and manually handle the observable yourself if you don't want to extend BaseObservable. 

Make your object like normal with your fields, getters and setters. Then you need to make your getters bindable by using the annotation @Bindable. this allows you to use the getter in the layout and still allow for private fields. 

The final thing you should do is call notifyPropertyChanged inside your setter and refer to the field that is being set. This will ensure that when changes to your model object occur your view get's updates as well. Otherwise you will not see things update when you change the model details. 

So now that the model object is complete and the your dependencies are set let's get to connecting the model to your view!

open up your Fragment's layout file, and update add a button to the layout and update it to match mine. I am overwriting the default hello world textview to use as my firstName and lastName textview. Feel free to place the button and textview however you want, the primary focus will be the databinding. 

<layout xmlns:android=""
    <data class=".UserBinding">
        <variable  name="user" type="com.darxstudios.databind.example.User"/>

    xmlns:tools="" android:layout_width="match_parent"
    android:layout_height="match_parent" android:paddingLeft="@dimen/activity_horizontal_margin"
    android:paddingBottom="@dimen/activity_vertical_margin" tools:context=".MainActivityFragment"

        <TextView android:text='@{user.firstName+"  "+user.lastName}' android:layout_width="wrap_content"
            android:id="@+id/textView" />

         android:text="New Button"
         android:layout_marginTop="160dp" />


This is where things got a little confusing and took me a bit to understand. so let's start with how this works. 

  1. The binding framework has to be put into a <layout> tag, which means you will have to ensure the xml namespace is now in the layout tag and not the RelativeLayout. (the xmlns attribute. 
  2. The <data class ".UserBinding"> tag defines what binding class the framework needs to generate. This is the key part, by defining what the binding class name you want here you will be able to reference it once we get to the Java part. 
    *Note: If you name it and make the project, and then want to change the name you will have to clean the project and remake the project to ensure the old bind class is cleaned up."
  3. add a <variable name="user" type="com.darxstudios.databind.example.User"/> tag so that the generated binding class understands what type it needs to bind with.  the name can be anything you want to call it, just like when you define a field. The type needs to be the full package path to your data type. 
  4. Now anywhere you want to reference the data bound class object in your layout, say a TextView you need to add @{variable.field} allowing you to combine like i did in the example @{user.firstName + " " + user.lastName} 


Now for the final part, how to hook up the fragment to the layout. This is actually really easy now that you have setup everything else above.

package com.darxstudios.databind.example;

import android.databinding.DataBindingUtil;
import android.databinding.ViewDataBinding;
import android.databinding.tool.Binding;
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.Button;

import com.darxstudios.databind.example.UserBinding;

 * A placeholder fragment containing a simple view.
public class MainActivityFragment extends Fragment {

    public MainActivityFragment() {

    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                             Bundle savedInstanceState) {

        final User user = new User();
        UserBinding binding = DataBindingUtil.inflate(inflater,R.layout.fragment_main, container, false);

        View view = binding.getRoot();

        final Button button = (Button) view.findViewById(;
        button.setOnClickListener(new View.OnClickListener() {
            public void onClick(View v) {

        return view;


So although  it is just a few lines it can be a bit complex. 

  1. Create your model object in the fragment,  and let's change how the inflation works. Type in UserBinding, it will then ask you to import the file. Do the normal Alt+Enter to import it. 
    *If it doesn't exist click Build -> then Make project, this ensures that the databind class get's generated "  
  2. Change the inflater to use the DataBindingUtil and inflate. 
  3. Use the UserBinding object and bind the user to the inflated view.
  4. To get the view for the onCreateView use the bindingObject.getRoot() method.  

AuthorMichael Cameron

Android Wear seems to be coming along quite nicely, while at I/O this year I got to play with their code labs and make an "Always On" App. It is really enlightening to see how these apps are made. I have made other wear apps for demo purposes for clients but was missing this critical always on feature. 


Always On

So what is it? and how does it work? 

Put simply, you can have an app with always on enabled and it will not terminate the app when the watch's display goes dim. This way you can have your app stay on the screen as the primary display on the watch. 

Before the always on system you would have to override the default system setting and keep your app from going into the dim display mode. This is a very bad practice and should not be done. Instead just convert it into an Always On App



How it works

Just like how watch faces work, alway's on apps have two modes. Interactive and Ambient. Interactive is when the user is focused on the app and is actively "interacting" with it. On the flip side, if your user is not actively touching the app and the system went will dim the screen and put it into an "ambient" or "sleep" mode. 

On thing to note is, by default  when your app goes into ambient mode the screen is refreshed once a minute instead of as soon as the layout item is updated. This is configurable to update faster, but really think about it before making the refresh happen too soon.


Enabling Always On

To enable Always On in your app do the following: 

  • Ensure the app is running on an API 22 or later sdk version.
  • Add "provided ''" into the dependencies in your gradle configuration.
  • Add the permission "<uses-permission android:name="android.permission.WAKE_LOCK" />" in the manifest
  • Also add "<uses-library android:name="" android:required="true" />" in the manifest
  • You will have to get the window and set the flag to keep the screen on
    • "getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);"
  • In onCreate setAmbientEnabled() and have your activity extend WearableActivity

 There are also many more things you need to do, such as listening to onAmbient events and setting the color of the layout based on ambient or interactive mode. I really recommend anyone interested to take their course on enabling an Alway's on app here:


AuthorMichael Cameron

I have been searching for the best productive system for a very long time. In my search I have come up with many systems  and learned more about existing ones. 

Here is a small list:

  • Getting Things Done™, (GTD) by David Allen
  • Agile - Scrum, Crystal, Lean 
  • Kanban 
  • Waterfall 
  • Simple Pen and Paper with lists. 
  • Google Calendar | Outlook Calendar reminders 
  • Post it notes 
  • Evernote 
    • Writing notes, adding reference, follow up
  • One note 
    • Writing notes, adding reference, follow up

I am pretty sure I have missed a few tools and habits that I tried to use. The honest truth is I don't believe there is the one silver bullet of productivity system to solve all your needs. The reason for this is because each person's situation is different. Their day to day lives are different, and that is okay. 

When I broke down and realized that these systems were not working for me in the way they were defined I almost gave up to the chaos. In fact for awhile I did. It wasn't until I found a combo that I really like.  You are all welcome to take my system and modify it to your needs or start from scratch on your own. Let me know if you do! You can tweet me here @Darxval 



After my failed attempt with One Note I decided to take another look at it, as well as another tool. A tool called Todoist.  And decided started to use them in unison. And just for reference I am using OneNote on my tablet as a writing notebook. 

My Tablet being a Samsung Note 2014 10.1, see image source.

 I really enjoy writing on this tablet and OneNote. It actually replaces my need for a physical notebook that I never look at or the paper becomes faded from my fast writing.  I also learned more about Todoist, My first attempt at using it was unsuccessful. I just never stuck with it.  In fact it didn't click until I changed the standup's at my work for our agile process that things started to make sense and emerged a new system of productivity. 


I changed the stand up's from being "What are you working on" to...

  • What did you accomplish yesterday? (Be Specific!) 
  • What will you accomplish today? (Be Specific!)
  • What is blocking you ? 

Alright so what is my processes? 

Todoist is my driving force for me to stay on top of things. I have a reoccurring task called 

  1. "Plan for the day" 
    1. I then answer those 3 bullet points, these things that I write down are the things that HAVE to be done today. 
    2. Once I am done my "planning" isn't over yet. I think of all things that have happened maybe I got a new task i need to start but not now. My wife may have asked me to do something in the near future. 
      1. I write down all of the things that I need to do sometime soon, or would like to do.
        1.  This piece is taken from GTD and allows me to not worry about not having a task recorded of what I need to do. This way I am not draining any of my mental energy worrying about a task I need to complete. 
      2. I also check my previous day's notes and see if I need to add anything to my inbox or today's accomplishments or not. 
      3. Once I am done I take all those tasks I wrote down and put the one's to Accomplish for the day into Today and it's own project (it probably already exists) 
      4. The rest of the ones that I would like to get too go in my inbox, without a date attached, unless I know it needs to be done before a date. I call this inbox my backlog. 
        1. This is taken from Agile, it is my series of tasks that I would like to get too, but they may change, or even become obsolete and that is okay. 
      5. If you do not have enough things in the Today's view then you look through your "inbox" and find a task you can pull in and accomplish. 
  2. The most important step, You do the tasks! 
    1. With these tasks recorded you can see what you need to do for the day and find out what things you can skip on such as meetings you know won't give you the value you need to sacrifice time that could possibly damage your possibility of finishing your task. 
  3. What if you do not complete your task
    1. Hopefully you don't, but we are all human :)  In this case, I just move it to the next day or if it's not that relevant I put it back in the inbox until I know i can address it.  The biggest driving force for this is if it is needed by work, school or something external.
  4. Rinse and Repeat
    1. Every day I go through this same motion and it helps me to stay on track, you have to be consistent otherwise the system will not work. 
    2. I ended up ensuring that I make it to work early every day so I can have this time of daily planning before the hectic day begins. 


Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus


AuthorMichael Cameron

Google I/O has been an amazing experience and I believe that anyone who is involved in the Google technology stack should be involved in either going to I/O or at least watching the streaming and recorded sessions that get uploaded online. This year was great, even though people seemed to be focused on wanting free stuff.

Google I/O should be about understanding the details of the technology more than what freebies Google and its partners give out. 


M Developer Preview 


App Permissions

Unveiled at the keynote address for the M preview operating system was the new app permissions system. This style mimics the way iOS does permissions in that it will ask the user if it is okay to use a permission when the application requests it. This should help to reduce those apps that do some very bad things when on some users phone. Such as data mining or accessing data that they do not need to be. 

One thing I thought of was the number of applications that use the Internet permission and thinking how many times the user has to allow the app to run on the internet. Thankfully Google has actually thought of this too. When an app is installed any permissions requested that fall into the PROTECTION_NORMAL category are granted immediately at application install.  Internet permission falls under this category.   



Developers should still be careful about permissions even if they fall into the PROTECTION_NORMAL category as they can still be revoked at any time by the user in the app settings menu. So developers are should to do the following: 

  • Always Check For Permissions - Before just assuming the action you are going to perform is approved by the user check to see if the permission is approved. 
  • Handle Lack of Permissions Gracefully - Just because a user denied you the permission to it's bluetooth doesn't mean your app should crash and yell at the user. If your app only works with bluetooth explain it to the user nicely. Always think of a good user experience.
  • Permissions are RevocableYour app may be able to connect to the internet now but maybe they thought your app was sending too much data and is turning off apps with internet to locate the bad app. You need to be aware of the chance that any permission will be revoked and have your app work regardless, even if that is a simple offline view asking the user to enable the permission. 


Finally, Do not overwhelm the user with permission requests. Use only what you need when you need them. The user can easily remove your app thinking it was too annoying. 

You can read up more about it here:


Chrome Custom Tabs

When I was watching the keynote I didn't understand what Chrome custom tabs were for at first. I thought it was a tune up on webview. 

Chrome custom tabs is a way to use chrome and your app in a more seamless manner. It allows the developer to control the web experience and native experience in a more personal manner. The developer can have a custom transition to opening a page to a chrome tab using the theming for the app and add custom actions to the chrome toolbar and overflow menu.  It also allows the developer to prefetch the content of the chrome tab before launching it. 

So if you are curious as to when you should be using a chrome tab instead of a webview here is what is recommended by Google Chrome developer page. 

If you have content that needs to be hosted inside the app, such as an integrated experience of both native and a web page then a webview should still be used. If you are wanting to hand off the user to a full web page but want the experience to be the same as if you are inside the app then you would use a Chrome tab.  

To learn more check out their developer page here:


App Links

App links are an interesting new addition. Taken from the open source App Links that Facebook started,, it allows apps and urls have a closer connection. How it works may seem a bit convoluted but in the end can help to be a great way to get users on the web or other apps to get moved to your application rather than some app that works with a similar MIME filter. 

Website owners need to explicitly call out their association with apps on their site in the following format:

http://<domain>:<optional port>/.well-known/statements.json
//And the following JSON format set for association
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "<package name>",
    "sha256_cert_fingerprints": ["6C:EC:C5:0E:34:AE....EB:0C:9B"]

The SHA256 fingerprint is your app's signing certificate. You can retrieve this value using the Java keytool. 


A good example of this is, say you have your own recipe app and you have your own associated website. you are on the website via chrome and you see a recipe you want to add or open to perhaps add to your own personal recipe book within the app. By tapping the link it will know that your recipe app should be opened and use the protocol to achieve the action you wanted to take.  

Or say you are on Hangouts and someone sends you a twitter link, you can tap the link and instead of Chrome opening to the twitter page you will open Twitter app and see the tweet. 

But, let's say you don't like the Twitter app, maybe you want Plume, or HootSuite to open instead of Twitter. You can easily override what the default app links are in your "default apps" settings and choose your favorite twitter client. 

Learn more here:


Android Pay

It is great that Android has fired back against Apple's Apple Pay with their own Android Pay.

How it works: 

When you go into your favorite coffee shop and see they have the Android Pay logo on their Point Of Sale system you pull out your phone and open the Android Pay App and select your card. Then you have your card over the checkout system. The system will connect and give the merchant a virtual card that is not your credit card and is unique to this purchase. This way the merchant does not keep your credit card information. 


The other benefit is that this can also be done within an app you make, perhaps you have a digital or physical goods store in place that can be ordered online. You can use the Android Pay to pay for those goods and is supported by the major credit card processing platforms like Stripe. 

Learn more:


Fingerprint Support

One of the hardest problems to solve for mobile apps are the ones that have user accounts. You want your user to be able to have a personalized experience but you also know that apps with a login screen are not guaranteed to be as popular as those without them. Well now google has developed the fingerprint scanner API into Android M so that you can get your users inside your apps much faster. 

You can now authenticate your users via fingerprint scan and check how recently the user was last authenticated. In order to accomplish this you need to have the USE_FINGERPRINT permission and use android.hardware.fingerprint.FingerprintManager and then use FingerprintManager.authenticate() to initiate the authentication process. 

The recommended way of using this system and the last authenticated time is to allow the user to login and then not have to re-authenticate until a set time.  

Learn more here:



The biggest problem with android hardware has been how you can have a tablet or phone and you are not using it that often seem to die just as fast as the devices you are using on a regular basis. A common practice is to have a tablet that is by your night stand that is used for reading at night. But otherwise it is not used. On iPad this scenario works fine. This is where Doze comes in. 

What Doze tries to do is learn the active habits of the device and put it into a deep sleep. reducing the number of updates to happen on a device during a doze cycle. It is still possible for developers to overdo data refresh calls and ruin user experience by killing the battery. 


It accomplishes this by limiting the number of background processing that an app can do while your app is not active. Doze may limit network access, suspend background tasks, notifications and ignore wake requests and even alarms. 

It is recommended that you test how your app behaves during a doze state. 

Learn more here:

USB 3 Type C

This might seem like a minor announcement, but I actually believe it is a much bigger win for the platform. So why is it such an a good thing?

Well here is some good points: 

  • It doesn't matter how you plug it in, there is no wrong side. 
  • Faster charging for your devices
  • Would allow you to be able to pass display information with the port instead of a required HDMI port. 

As long as the USB is a 3.1 type it also has these benefits:

  • USB 3.1 bandwidth is 10 Gbps 
  • USB 3.1 is backwards compatible to older models with an adapter. 


USB 3.1 Type C more information:

USB Type C:

Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus

AuthorMichael Cameron

Also Known As: No Object-Oriented AntiPattern "No OO" 


In general this AntiPattern occurs from procedural developers coming into an object oriented language. This could be that an old procedural system is being upgraded to a supported platform or even being added to a mobile device and needs to be rebuilt for that platform using the same guys who wrote the procedural C version. 

Detecting Functional Decomposition

This is an interesting AntiPattern because it is actually a good procedural programming pattern but a bad object oriented one. The pattern is defined as having all your code running in a "main" or LISTENER method that does all the work and creating function classes. These are classes that contain one method that do all the work translated from the previous codebase. You could also see no way to explain how the current architecture is working making it hard to find reusable components (sometimes just impossible to reuse). Classes that make no sense, and finally frustration and hopelessness from the testers, if any. 

AntiPattern in action!

So how about seeing this AntiPattern in action? Let's pretend we have a subscription offering system we built in Basic or C and now we are upgrading this project to allow users to subscribe via a smartphone or website. To do this we will first take a look at our old system which was handled by a clerk who entered all the mail sent subscription notices. But we want to allow our users to subscribe instead of worrying if our clerk took a sick day. 

So our Basic Dev guys took this on with no worry and replicated the system. and check out their new system below. 

The system adds a new user then update's their address. Then users add a subscription by going straight to calculating the subscription cost and cost of shipping then calculate a reoccurring payment schedule or alters any  schedule they already have. The user can then delete the subscription and goes through the same process and ending the process with an alter to the payment schedule to be not reoccurring. Brilliant!

Well not really, the procedural programmer creates classes for each function instead of a true associated object. So what do we do now ?

The Solution! 

So what do we do? Well we gave our guys some Object Oriented Schooling and after having only one drop out and graduating the rest to official Object Oriented Design. They then took apart their system and redesigned it with Objects in mind. A user, a subscription, and a payment object. Then moved the associated work to the proper objects. Check out the solutoin

This can be summed up as the problem being that the core developers are completely inexperienced in object oriented design and just plows through the implementation.

Final Thoughts 

I also mentioned in a joking sense about drop outs from the Object Oriented design school because you will have people who will resist the move to OO based systems and they will either Quit or be Fired. You should also not expect the employer to train their employees in the Object Oriented System, they might be more likely to fire all the employees and hire experienced Object Oriented Developers. 


Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus


AntiPatterns - The survival guide to software development processes

Personal Experience




AuthorMichael Cameron

When you write a lot of code professionally there is always an abundance of "saved" code you want to reuse. This is a good idea, as we should keep code around we want to reuse in a toolbox. But you can easily turn this good idea into a nightmare. 

As you have assumed I am talking about cut and paste programming. This is where you go and find your saved code and copy and paste it into your current program and say "Wow, I just saved a couple weeks of development! Done!". When in fact what you did was create a maintenance nightmare. 

The problem comes when you take this existing code and try and make it fit with your codebase. If you are not familiar with refactoring and good Object Oriented design then you can easily create a fragile system. Such as the following

Symptoms & Consequences

  • The same software bug reoccurs throughout software despite many local fixes.
  • Lines of code increase without adding to overall productivity
  • Code reviews and inspections are needlessly extended
  • It becomes difficult to locate and fix all instances of a particular mistake
  • Software defects are replicated through the system
  • Inflates number of lines of code developed without the expected reduction in maintenance cost associated with other forms of reuse. 

If you ever have to cut and paste be sure to have a plan to refactor it sooner then later otherwise you will have a heavy maintenance cost as well. 

The Solution!

This can actually be a little difficult. You must first understand how your code is implemented. Then should look into black-box reuse so that you can reuse this piece of code where you need it instead of duplicating it everywhere. you can use interfaces and run-time mapping to bind these objects to various parts of your app that needs to run this feature code. 


Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus


AntiPatterns - The survival guide to software development processes

Personal Experience

AuthorMichael Cameron

Ludum Dare 30 has come and gone but I wanted to share my experience of this last competition. It has been awhile since I last participated in a Ludum Dare. The last game I was trying to make was Block Wars back in 2011 using Unity3D. 


Prepping for Ludum Dare

This was certainly a pain point for me. I had planned to watch all the Unreal Engine 4 tutorials ahead of time and build a small racer using assets from But l really didn't take into account how busy I am on a daily basis. Being married, full time job, two kids and taking some classes. So I never got anywhere with the unreal training videos. Honestly though it was a problem of me not planning properly. 

One unexpected thing that occurred was my hunt for an agile tool that would allow me to do four hour sprints. I looked at planbox, JIRA, Axosoft, TouTrack, and Mingle. While none of them had this ability built in, I messaged each of the tool providers for a way to come close to a four hour system. Out of all of the agile tools I contacted only Mingle contacted me via email to expand on this four hour sprint idea and my reason behind doing it. This lead to a phone call I had with them explaining that I was participating in the Ludum Dare which requires 48 hours to make a game (minus 16 hours of sleep) so I wanted to make a way to present every 4 hours a showtime of work progress. After explaining this I was invited to a web conference with an admin and showed me how their card system works and a way I could replicate this workflow. I highly recommend them so check them out and see if they can help you with your next project. 

The Ludum Dare Weekend

The Ludum Dare started at seven PM MST on Friday August 22nd. It is really surprising how popular Ludum Dare is because the site was inaccessible for at least 15 minutes. When I was able to get in and found out the theme was "Connected Worlds" I decided to take my time coming up with an idea. I wanted something fun and I wanted to try and make it small enough to build within timeframe.  I had a thought of a Zelda style game with realms of monsters along with other too large ideas. I finally came upon the idea of a platformer with obstacles you have to "shift" away from in order to complete a level. 

I dreamed of a great experience with a live stream and knocking out great content sprint after sprint. What truly came about though was a live stream of youtube videos and minimal development with the unreal engine . I did learn a lot about how the Unreal Engine system works and in fact was able to get a simple prototype going where the character "shifts" to other worlds to complete a puzzle and finish the level. But that was all it was a prototype. In fact I almost submitted it as it was but I felt that it didn't meet my done criteria.

Sunday Morning was by far my most productive sprint. I should have live streamed it as all the videos content came together and allowed me to build out the shifting logic from blueprints alone. Granted it was the only productive sprint of Sunday as the rest of the day I was busy with family obligations.

Final Thoughts

In the end I am glad that I participated. I plan on continuing this project properly and posting it up here on my blog. 


Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus

AuthorMichael Cameron

Let's talk about ghosts, and gypsy's! In this edition of Monday AntiPatterns I want to discuss the Poltergeist AntiPattern. As well as its awesome refactoring solution "Ghostbusting" 

Understanding the Poltergeist

Poltergeists are the restless ghosts in some code architectures. By this I mean there is a mysterious controller or "transient" class that is stateless and all it does is invoke a process on another object. Afterwards it promptly vanishes. Its sole purpose is to call methods that belong inside an object with a state instead of outside in statelessness.

Put bluntly, If you create a class that's only purpose is to tell some other object or class what to do and then deallocate and vanish until a similar operation is called than you have a poltergeist in your code.

The Solution

Who are you going to call?


That is right! we are going to do some Ghostbusting, yes that is the name of this refactor.

The Process - Ghostbusting

Honestly the "Solution" is pretty easy, you eliminate the ghost class, but like the ghostbusters you must find it first in your code and identify where this ghost "appears". You take the functionality it calls and move it to its associated class or state based and long living controller. 

This will of course leave none of your objects connected to do what the ghost was doing to complete your objective. You will then need to employ your design pattern and architecture skill to create a state based approach. such as allocating the object in a controller and have the processing occur in the model. or via queue that sends a notification when ready.

Whatever it is you need to understand the right architecture for your project and be aware of the wrong architecture that can handicap your project.

Causes of Poltergeists

  • Generally they is created by having a minor understanding of Object-Oriented Design.
  • Putting in code during a requirement analysis. stubbing something in can create a poltergeist that could evolve into a blob.


Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus


AntiPatterns - The survival guide to software development processes

Personal Experience





AuthorMichael Cameron

The Ludum Dare event has begun! and the theme has been announced! 

Theme: Connected Worlds

 I will be posting updates here as things occur

Update 1 

Some know this, But I have decided to use an Agile approach to this project, I will be running a series of 4 hour sprints hoping to see what I get from it and hopefully get some return. So Sprint 1 is over it is time to see how far I have gotten.


Sprint 1 

So because I have basically a complete lack of understanding of Unreal Engine 4 most of the time during this sprint has been youtube videos on learning. UE4 is extremely powerful. I probably bored some Stream watchers on Twitch but oh well. Current Progress is not to great, a bunch of videos watched and started the spike for understanding how to teleport the character around. 

  Completed Tasks and Stories: Introduction to UE4 Programming - 1 - Overview Introduction to UE4 Programming - 2 - Project Creation Introduction to UE4 Programming - 3 - Creating the Base Pickup Class Introduction to UE4 Programming - 4 - Creating a Battery in C++ Introduction to UE4 Programming - 5 - Empowering the Character Introduction to UE4 Programming - 6 - Creating the Power-up Material Fun with Blueprints : Spawning Dynamic Objects Introduction to Third Person Blueprint game - 1 - Intro  


Completed Tasks and Stories:

Introduction to UE4 Programming - 1 - Overview

Introduction to UE4 Programming - 2 - Project Creation

Introduction to UE4 Programming - 3 - Creating the Base Pickup Class

Introduction to UE4 Programming - 4 - Creating a Battery in C++

Introduction to UE4 Programming - 5 - Empowering the Character

Introduction to UE4 Programming - 6 - Creating the Power-up Material

Fun with Blueprints : Spawning Dynamic Objects

Introduction to Third Person Blueprint game - 1 - Intro


Update 2

So my neophyte knowledge in Unreal hit me hard, so it was a major step in only video watching, Sprint 5 was the actual momentum result...

Sprint 2-4

  • A bunch of videos so didn't bother with livestream...


Sprint 5

  • Actually made shifting work out.. started simple then expanded.


And then went further to make some theming for platforms. hooked up the shifting From world A to B for all possible shifting starts and ends... which took a lot...  as you can see in my circuit below

But I finally got some measure of shifting working out. It is no where near polished and actually really enjoy the idea of this game. So regardless if I make the deadline or not i will complete this game and post it up on this blog page.

Feel free to check out what others are doing at Ludum Dare 

AuthorMichael Cameron

So a few people out there may be aware that this weekend is the next Ludm Dare Event. If you are unfamiliar with Ludum Dare then hopefully I can try to entice you on how great it is.  

The Ludum Dare Event is actually a competition where you have 48 hours to build your game from the Theme that is generated based on 5 rounds of voting.  The event is meant for solo developers to use tools they have, some engineering know how, and most of all creative inspiration to build their game. 


Ludum Dare Challenge  

There have been so many questions on the rules that they were given a post by the admin with explicit clarification: Explicit Rules. Below I have the abridged version

The 48 Hour competition

  • You must work solo 
  • All content must be created during the 48 hour window, No taking from online sites or asset stores
  • Game must be on the theme
  • public libraries allowed 
  • template code and tutorial code can be used, but should be called out ahead of time, write most of the code during the window.
  • You can port after the 48 hour window if you want
  • You can do small bug fixes after the 48 hour window
  • Add your source code in the submission, for disqualification validation


There is another concept that runs in parallel that is called Jam. It is slightly different

The 72 Hour Jam

  • Same rules as above except...
    • Work with other people as a team
    • Do not have to submit source code
    • Free to use whatever artwork you want, legal ones would be best ;) 
      • Including art made ahead of time
      • ... and public domain
    • You get 72 hours instead of 48! 


My Plan 

I have already posted the "I am in" post on the Ludum Dare site, but just so everyone is aware I plan to use the following systems and tools

Game Planning

  • Agile project system
    • 4 hour sprints, 30 min retro, 30 min planning and then back at it. 
    • Create project definition and items for back log when theme is announced.
    • Create a plan (not design document!) for the initial sprint architecture, then run sprint by sprint. 
  • Notebooks and Whiteboarding

 Development Tools

  • Game Engine:Unreal Engine 4 
  • Programming IDE & Language: Visual Studio 2013 - C++ 
  • Art Assets: Blender & Photoshop
  • Sound: A tool called sfxr that was designed to be used for the competitions.

Other Tools

I wasn't sure I was going to do this, but I decided why not.. I am going to do a live stream from twitch that will be visible on Ludum Dare as well under the username darxval  

Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus


AuthorMichael Cameron
Also Known As: Dead Code, Winchester Mystery House

I can not remember the last time I didn't look at a codebase and see Lava Flow. It certainly amazes me how developers can be pushed so much into a bad design or a trial and error sequence shown in the code. But let me start from the beginning.

What is Lava Flow?

Lava Flow is a case where you come upon some code that you or any of your team mates have no idea how that thing came to be. Not sure if the implementation is truly necessary or if it has been deprecated. There may be some true production that is used from the outcome of some obscure method in the mess of the code.


How to tell you might have Lava Flow in your architecture

  • There is no architecture, or no architecture plan was thought of because super awesome developer B had a few ways of implementing it.

  • There are blocks of commented out code.

  • Code that is in progress that was merged or added to the main trunk/master of the source code.

  • Research and Development (R&D) code that was plugged in as production code without being reworked for the architecture.

  • Lack of cohesion in the code, it doesn't match the rest of the architecture and appears alien to those who read it.

The Solution

While many will want to preserve the code that is written what happens most of the time is that the code is entirely nuked. This isn't to say some hot shot developer came in and rewrite the best implementation ever. In fact it happens because the team stops adding to this flowing mess and defines the architecture of what needs to occur. By understanding what needs to happen the proper design should shine through, as long as the developers are properly looking for it.

Once identified the developers work as a team to create the new system and either seeing what parts of the code can be refactored per the architecture specification and the rest tossed. This will undoubtly create bugs or regressions. But wait until the architecture is firmly in place before fixing. and put some unit tests around them!

Preventing Lava Flow

To prevent Lava Flow is similar to the solution for having Lava Flow just less costly. You need to ensure that there is a defined plan for the architecture. An agreement on how the system should work and how to validate that it is working. We don't want to spend all our time writing diagrams on how things work but understanding the flow, and design is key. Without this you are bound to create Lava Flow in your system.

Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus


AntiPatterns - The survival guide to software development processes

Personal Experience

AuthorMichael Cameron

Design Patterns

Why use them?

Design patterns are a way to allow us to avoid anti patterns "bad practices"  while developing our architecture.  It also allows for readability of the code. Any well practiced software engineer should be familiar with design patterns and hopefully the antipatterns and see what the code is dong. 

You may say to yourself that your code is super readable and perfect, in fact you may say you have quite the clever and complex system that people would be jealous of. Before you run off to the tell the world I recommend you create a UML and/or a flow chart of how your app works and is connected. Hopefully you made this before you started. 

The following example is of an actual production released application...

The System call for Microsoft's IIS system

Quite amazing isn't it? That spaghetti code that I think would be insane to follow. If you didn't catch the caption, this architecture is the system call for Microsoft's IIS system. The windows web server if you are not familar with the term IIS. 

Makes you wonder how the Apache system is put together. Well I have that too.

Apache System Calls


The Apache web server is built on the basic principals of modules. It is not a mess to follow. It is a complex system but most services and applications are. So enough talk and theory lets talk about one.

The Strategy Pattern


Defines a family of algorithms, encapsulates each one and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. 


With the strategy pattern you extend your objects by swapping their behavior based on conditions or requirements. The best part is that each behavior is entirely encapsulated. Think about the Keurig image above. it is the physical representation of the Strategy Pattern. The swappable behavior is the kind of coffee a person wants. 

Just because we have a new flavor K-Cup doesn't mean we need to rebuild the coffee machine. When we develop we should think about the real world example and apply it to our code. By extending your code instead of rewriting it is a sign that your code is truly encapsulated, scalable, and well thought out. It may be an anti pattern pretending to be a "pattern" but it could always be worse, it could be a Blob.


A java example of the strategy pattern

// 1. Define the interface of the behaviour
interface Strategy { public void brew(); }          

// 2. Bury implementation
abstract class StandardCoffeeBehavior implements Strategy { // 3. Template Method 
   public void brew() {
      while (nextAction)
   protected abstract void    start();
   protected abstract boolean nextAction();
   protected abstract void    stop();

class GeneralCoffeeKCup extends StandardCoffeeBehavior {
   protected void start() {
     System.out.print( "K Cup seal pierced" );
   protected void stop() {
     System.out.println( "Contents have been delivered" );
   protected boolean nextAction() {
      System.out.print( "release special aroma and strong coffee with water that is being poured" );
      return true;


// 2. Bury implementation
abstract class EspressoBehavior implements Strategy { // 3. Template Method
   public void brew() {  
      while (true) {
         if (release()) break;
   protected abstract void prepare();
   protected abstract void distribute();
   protected abstract boolean release();
   protected abstract void reset();

class SuperStrongEspressoKCup extends EspressoBehavior {
   private int releaseCounter = 0;
   protected void    prepare() {System.out.print( " pierce k cup  " ); };
   protected void    distribute()  { System.out.print( " start distributing water.  " ); }
   protected void    reset() { System.out.print( " reset delivery system " ); }
   protected boolean release() {
       System.out.print( " release super strong espresso" ); 
       // we want three shots of super strong espresso
       if(releaseCounter >=3)
        return true;
    return false;

// 4. Clients couple strictly to the interface
public class StrategyDemo {
   public static void clientCode( Strategy strat ) {
   public static void main( String[] args ) {
      Strategy[] kcups = { new GeneralCoffeeKCup(), new SuperStrongEspressoKCup() };
      for (int i=0; i < kcups.length; i++) {
         clientCode( kcups[i] );

The biggest take away should be that the client code, the "StrategyDemo" is coupled to the interface, not any of the concrete types. the client class does not have to know how the behaviors are built just that it can execute them.

Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus


[Book] Design Patterns - Elements of Reusable Object Oriented Software 
[Book] Head First into Design Patterns
IIS vs Apache structure
K-cups picture
Keurig picture 



AuthorMichael Cameron

I am sure most of us go through college and our software engineering careers hearing and shouting the glories of design patterns. Specifically we start with the Gang of four book, Design Patterns: Elements of Reusable Object-Oriented Software. But something we do not talk about that we should discuss more are the AntiPatterns. 

So what is an AntiPattern? quite simply it is the industry definition of defective processes and implementation. Having actual terms for these AntiPatterns allow us to name the implementation snafu's and bad practices. 

"An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences." --  AntiPatterns - The survival guide to software development processes

How To Stay Ahead or Alter your AntiPattern Path

At some point in our lives we have all written that code, that beast of a architecture that should have never been risen. The trick of course is once this monster is born how do you turn it into a majestic creature of glory. The answer is actually pretty simple, iterative refactoring. Sometimes you may just kill the creature and start from scratch but from my experience and from others it is generally better to refactor the code.  


The Blob

Also Known as: Winnebago and the God Class

A true monster indeed, it starts out small and doesn't seem harmful, just like in the movies, much like them if there is no scientist out to save the day then the entire project may become consumed by the blob. 

The blob itself is a condition where there is a single class that is taking on all the jobs, it has the monopoly of application responsibility. It can be created from a prototype that just kept adding on features, or even a project that started with a well defined structure but became a blob after new requirements and iterations and no one spot checking the architecture to enforce a refactor or a new implementation of a feature. 

Blobs are also accompanied by unnecessary code, dead code, making it hard to determine what is useful and required and what is junk. 

Root Causes

  • Sloth
  • Haste
  • Lack of an object-oriented architecture - sometimes developers don't have any object oriented background, or limited background and believe what they are making is truly object oriented. 
  • Lack of any architecture - creating a complex system with no plan at all
  • Lack of architecture enforcement -  Generally you plan on a great design but during the code's development things change and if not properly monitored the blob can form. 
  • Too limited intervention - In an Agile world, its possible that after many sprints the class grows instead of creating new modules. 
  • Requirements are code - Sometimes requirements get taken as the way they are written in the document is how they are written in code, coupled and together. creating a disaster of coupling and blob manifestations. 

Symptoms and Consequences

  • A single class with a large number of properties, operations or both. 
    • A class with 60 or more operations/properties generally indicate a blob pattern.
  • Methods and algorithms in the class are unrelated, and therefore having more than just a single responsibility. 
  • In iOS this is easily spotted by having a God View controller that handles everything with a lot of data objects pretending to be an object oriented solution. 
  • Legacy code that has been transplanted from a different codebase and hasn't been refactored into the current architecture.
  • An unfortunate consequence is that the blob strangles OO by not allowing you to modify the system without affecting every part of the app.
  • A class like this is impossible to test or reuse, there have been some scary things like a blob base fragment for android that is reused but heavy and draining the app.

In truth, if you have a blob class you don't want to reuse it. if you do, then I am sorry for the hassle you will have to deal with. 

"This is the class that is really the heart of our architecture" -- Evidence of a Blob in a conversation. 

The Cure! 

How do we battle such a foe? its large and scary nature frightens away developers in a thought of "If I don't look at it maybe it will go away." Champion the blob by taking out your sword of Refactor. 

The refactor solution that helps us here is the Refactoring of Responsibilities. The key to killing the blob is to move behavior away from the Blob. It may be a good idea to move the behavior to the encapsulated data objects so that the objects are more capable than just a blank data object. removing the complexity of the Blob.

The following steps shows how the refactoring works. 

    • locate contracts in these related parts of the class that make a common focus, behavior or function that satisfies the requirement of your architecture.  
    • After cataloging your operations and properties find where they belong by either adding them to a data object or creating modules that can serve to carryout the needed requirement or algorithm, remember to keep it simple. 
    • If you have objects that reference an object that far coupled, for instance if you have a view controller that has a list within the list is a cell with an item, if that item and the main view controller have an association remove it!
    • It is normal that during the refactoring and moving behavior that some duplicate logic gets created, when appropriate move common code and properties to a common base. DO NOT CREATE ANOTHER BLOB! but move what is related, refactor code that seems like every object should take advantage of method A or Property A. 

Some fast paced shops make it really hard to completely get rid of the Blob, but if you take some time and iterate on it even an 80% refactored solution is better than the giant blob that can take down your entire project.


Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus



AntiPatterns - The survival guide to software development processes

Personal Experience



AuthorMichael Cameron

Resources in Android

Android uses the concept of resources, these resources can be almost anything. From a sound byte file to a layout for the window or just a single value to determine what the title of a dialog box is. These resources get a generated id for the application to take advantage of, the content itself can be changed and allow the app to have the change without recompiling the source code. 


String Resources

Lets talk about one of the first things any Android developers come to learn,. the "Strings.xml" file. 

The strings.xml file is a resource that contains a bunch of strings you can reference in the UI designer or with your code directly. This differs from Apple's approach where you define strings in the code file or interface builder and attach label outlets for them. But you can replicate this with .plist files.   

What is the point? well this allows you to not worry about hard coded string constant files and having to deal with finding a way to reference it without creating bad coupling.  see example below of a sample string resource

<?xml version="1.0" encoding="utf-8"?>

    <string name="app_name">Android Resources</string>
    <string name="hello_world">Hello world!</string>
    <string name="action_settings">Settings</string>


When android see's the above layout it generates or updates its file with unique IDs for each of the string resources specified.  it even creates a static inner class to give the strings its own namespace. see sample below:

package com.darxstudios.androidresources;

public final class R {
// skipping some code to create brevity. 
 public static final class string {

        public static final int action_settings=0x7f050000;
        public static final int app_name=0x7f050001;
        public static final int hello_world=0x7f050002;
... // skipping some code to create brevity. 


One of the first things you may notice is that the resources are associated as int's and not strings. This is what creates the link between layouts and actual java code, for example R.string.app_name; and you pass that to a resource method. like FindViewById(resourceId);  

Another thing, the file does not have to be called string.xml it could be my_awesome_string_file.xml  you can even have string1.xml and string.xml  and android will be smart enough to take both the files and create unique ids inside that string class. 

Layout Resources

A layout is your screen, similar to a webpage of HTML. it defines how the content is laid out. see example below.

Sample Layout 

It may actually appear that I am hard coding that "Hello World"  but that actually is android studio trying to make it easier to see whats going on on the file if  you click it on it you can see the true input of android:text="@string/hello_world".   Just like the strings file this file is also compiled down into that class and referenced as an int. 

public final class R {
.. // truncated for brevity
   public static final class layout {

        public static final int activity_my=0x7f030000;

.. // truncated for brevity

this is extremely useful because in the code you actually reference the layout you intend to load when your activity ("window/screen") appears. 

public class MyActivity extends Activity {

    protected void onCreate(Bundle savedInstanceState) {

The setContentView is what achieves loading your view. After the content view has been set we can go through and grab the objects referenced in the layout by<resourceInLayout> 

if I were to add android:id="@+id/helloWorldTextView  to the TextView element inside layout the id gets generated and added to the class. 

    public static final class id {
        public static final int action_settings=0x7f080001;
        public static final int helloWorldTextView=0x7f080000;

This also works for strings, you don't have to explicit set each string in the resource file, you can add them as you create your layouts by using the "@+string/string_id_name"  android studio will also have a quick wizard for setting the values. 

Compiled versus non-Compiled resources

In general all resources get a generated id in the regardless of where they are added. but if you have a file that you did not want compiled down to binary for the application you can actually create a folder in the res directory called raw these files are not compiled into binary for the app. They do get IDs generated for them but allows you some flexibility for the app. 


Resources expanded

There are many different resource types here are some that should be mentioned as well

  • Color - create color resources to reference in file to ensure the theme of your app is always the same 
  • String arrays - create an array of string resources, perhaps you need a default list of a table to show off some content or how something works. 
  • Plurals - An awesome system that deserves a post of its own, a collection of strings based on the value of a quantity. The quantity is a number, this is a major gain for localization since multiple different languages use plurals differently and this system allows you account for it easily.
  • Images - in the drawable folders you can use jpg, gif, png, etc. each image get's its own ID based on the filename. it is recommended to add various different density sized images for various screen resolutions. (This also includes stretchable images, known as 9 patch {another topic that requires a different post} where the image is noted as *.9.png. which is a image that allows you to stretch without losing quality of the image. 
  • *.* - create your own resources that you need android is flexible enough for you to add resources that you want, you will of course have to build support for that file type if its not already supported by the java/android framework. 


Feel free to check out the source of this example app here


Thank you for your time 

Feel free to comment or contact me through any of the following connections

+Google Plus


AuthorMichael Cameron

Before you can begin to start developing your product you need to come up with one. It may sound easy at first but it can actually take a lot of work. Between having so many different ideas and features to go along with them you can easily create a bloated project that is of no value. 

How do I create value for a project that doesn’t exist?

There is that word again, value. so how do you create value for something that does not exist? What is value? and How do I calculate it? 

Well to answer even that you need to decide what type of project your making, whether it is an app in the app-store, a video game, hardware, the restoration of a car, Choosing your type also depends on value. In this case is it valuable enough for you to spend time working on this project. 

What is the end goal for the project? Is it money? Knowledge? A portfolio? Depending what your end goal is for the project you align your value with that. From there you need to ensure your project matches your end goal and not the other way around this is the time to ensure you choose what is best for you or your company. 

Remember the time you put into a project is a cost, just like the cost of paying any third party for services, etc.

Okay, you have your idea, kind of now you need to come up with what your project will look like. Whatever you do, do NOT create a "design document", do not spend hours upon hours writing specifications. What you do need to do is envision your idea, write down everything as it pertains from a the consumer of the product. You should not do any "implementation" design. Write down what the end result would be. If it is a game write down the game play, explain how the game is played, whats the player's goal, the environment, the setting, write down as if you are playing the game right now.  But most of all write down the core game component. Do the same if it is an app, find the core component that makes the app worth using. Build up your idea around the core component.  Push out implementation details until the team is developing, they are the ones to solve that. Yes even if it is you doing the implementation later, In this case "Procrastination is good".

One other thing to mention, be jazzed about your project, if you are not excited for the project and want to do it, then i doubt it will get done, once you "commit" to this it can not be stopped, you should never passed the imagine stage if you are not willing to put a year's worth of time into it. it may take a few months to complete it, but there is still supporting it after. But you should always have a reason for it to be completed and stick with it!

You should also time box your imagine stage, put something together that is complete at the end or even several "time box sessions", but limit them. Too much imagining will cause you to stay in this stage too long and add too many features that will just ensure your project is never done.   Once you have your Product and "idea" can be explained and shown to others you are ready for the Planning stage. 

AuthorMichael Cameron

Over the last few weeks I have been learning and putting into practice an adaptive Agile method for being productive at my job, and personal life. The results so far have been great and I am actually surprised at how productive I am and actually see how productive I am during a sprint.

I wanted to have a mini series post about Agile and explain how I learned to make the system work for me both at work and at home. 

Game the system!
— Karlheinz Muenchow

The formal training I received was from Karlheinz Muenchow, I learned a lot but the premise of it all was for the core team to become more and more productive by being more and more innovative.  You need to know the cost of doing features, or even considering a product. But even more important is to know what the value is for doing it. if the value is greater than cost, then maybe it is worth it. 

Nowadays people know the price of everything and the value of nothing.
— Oscar Wilde

If you don't know the value of something is, how do you know how valuable it is? answer is you don't. When nothing has a value then somehow everything becomes priority 1.  

So why agile? Why not say use waterfall? 

At my job we have used waterfall for the whole time I have been there so I was hesitant to change at first too.

Did you know that when waterfall was invented the actual inventor said not tot use it, that it in fact has flaws in its design. The initial waterfall method actually had a couple more arrows to go back to development and planning after testing.

The thought of testing after the project or core code is complete actually bad practice, so is believing you can design and write up the entire application from start to finish with no changes in a "mythical design document".  I have been through enough projects that design and requirements change during implementation, the first thing to go is the timing for a proposed project and so your project already loses its ground of being the perfectly designed and executed project. 

Not sure your familiar with waterfall check this link:

or better yet check the video below for a simple glimpse into what waterfall is and its issue.


In an overview of agile planning and execution would go like this. 

  1. Imagine your product 
    • This means go into as much detail as you want or what you envision your product does.
  2. Plan 
    • Create Your core team, separate the pigs from the chickens, define the Product Owner if not already defined (generally the guy who came up with the product in the first place, but not always), and Scrum Master 
    • Have the Product Owner write down everything that would be in the app  from a user/stake holder view point. It should be an overview of user interaction or stake holder requirements. Not an implementation design document. (Anytime anyone wants to make a design document STOP!) |
    • These generic user features are stories the PO (Product Owner) will order these by most valuable (highest ROI) once this is done the core team (the guys who actually do the work) will help reorder the list by dependency whether its architecture or a third party dependency. 
    •  The team will then define how long the sprints, 2 weeks being common, and the core team estimates using relative estimating on how much work the entire product will be.
    • The product has a defined end date generally before the core team is even created. So at this date the MVP (minimal viable product) must be achieved and it is up to the PO to order the backlog (stories the core team has yet to commit to) to match the deadline.
  3. Commit
    • he core team commits to the stories of most important or dependency and tries to complete all of the stories, its not uncommon for the first sprint to take on more work then you are initially capable of.
    • The teams velocity is determined by how much work they can get done in one sprint. each sprint there is a chance for it to increase or decrease and this helps plan out to see if the project is on track or is in danger and things to need to change. 
  4. The Sprint
    • This is when the music starts playing and the core team chugs along to build the product and complete all the user stories, user stories are broken down into tasks and any unclear items that wasn't addressed during planning are brought up to the PO.
  5. Showtime! 
    • At the end of a sprint it is time to show the PO what you completed, every story has a deliverable, something tangible that the PO can say yes this story is complete.
  6. Retrospec
    • The core team looks at what happened during the sprint reflects on what went right, what went wrong, and ways to improve the process
  7. Adapt
    • The team changes some processes (maybe) checks there velocity to know what work they are capable of currently.
  8. While Project Not Done - Continue Sprinting
    • The team jumps back to the planning stage re-estimates the work and goes through the process again until the project is complete.
AuthorMichael Cameron