Adventures in Story Points

Story points are a corner stone of the agile development process, giving a key piece of information from those that implement the story to those that decide what gets built. It’s not the only piece of information that goes into planning at the product level, but it is the most important from a process point of view. Story points don’t just estimate how long a story will take, but bundle in estimates of technical risk and uncertainty. From a PM’s perspective two stories can sound the same, but end up with a large gap in the estimated story points. This could be because the engineers are deep within the code base that pertains to one story and not the other; and thus feel more confident about exactly what needs to be done. Or it could be because some things sounds easy to implement but aren’t. In my days as a consultant I’ve seen story points described in a few different ways:

  1. The number of days an engineer thinks it will take.
  2. An estimate of the size and complexity of a story; time estimate + risk factor
  3. A comparison of how big one story is to another; story1.size == story2.size

The pure agilest will tell you that story points are #3, but in the real world its hard to compare the size of a story with another without giving an inherent engineering hours estimate. Where teams get in trouble is when they start measuring their velocity from one sprint to the next as a ‘team performance metric’. If engineers get hounded when their velocity dips they are incentivized to either over-point or give points in terms of time, aka method #1 which is a flawed way of pointing a story. Points are for size which why we estimate hours for story tasks during sprint planning as well, because you have the best ability to judge how long a task will take right before you start it. If you point a story, and it sits for six months in the back log and then comes out and the assumptions around implementing it have changed, like say it was pointed assuming a certain library would be available and now the legal team has nixed using that library, then you’re going to be in trouble when it comes to measuring your velocity. Ideally you’d re-point anything that has sat around that long, but unless someone flagged that story as dependent on library xyz then the team might miss the fact that it no longer has accurate points.

A team’s velocity will change over time. So using story point velocity as a golden ruler of performance will make for a lot of unneeded stress. As a project moves from laying the architectural framework, to fleshing out all the details the team will gain or lose velocity depending on everyone’s abilities, throw in team member churn, ramping up new members, triage meetings to support legacy code, taking time to fix bugs and seeing a downward velocity in story points per engineer per sprint isn’t unheard of.

So how should you use story points? There is no perfect solution. And that’s what agile is all about. You have to find the right implementation for your team. How’s that for copping out of a decent answer? On a more specific note I tend to favor deciding how many points an engineer should take in a sprint first, and then using that as a measuring stick for how big a story is. As an added bonus to help keep story points consistent over time I find it helpful to pick out stereotypical stories during sprint closing as a reference for future grooming.

Story points are an integral part of the agile development process, and it’s one that is often contentious.  I’ve found it helps to have a written definition of the teams interpretation of story points (a long with all other process terms) to ensure everyone is on the same page.  So, don’t fall into the trap of militant Points per Sprint velocity measurements or bickering about what a story point means each print. In the end, story points are what you make of them.

Tech Strategy – Change the Game Part 2

The large storage future smart phones?

 

What would some use cases be for a smart phone with lots of storage space? The first market that comes to mind is the developing markets where cell data is expensive and slow for most people. The second is just comes from enabling better customer experiences through a faster user interface. The third is in gaming and video streaming.

 

Think of an app like Yelp, if yelp could store it’s top N restaurants in the current city for the user, then they could zip through the interface in their search for a bite to eat instead of waiting on a network call every time they wanted to see the next 10 restaurants or wanted to switch category filters.

Or Amazon prime instant video, enabling people to download HD content at home and watch it on the road without burning their battery life and data plan.

Or maps that don’t have to reload tiles each time, and could cache the users common routes on phone so the user gets their directions faster and with fewer privacy concerns.

A business user could take their entire email history with them and be able to search through it while on a plane.

The downside is that phones are lost/stolen often and that could create more of an information security hazard, but I’d wager that if people are willing to turn their phones into credit cards, car keys and garage door openers then they shouldn’t be afraid of a thief seeing which Amazon movies they have downloaded.

Higher storage devices would enable streaming like services that don’t always need an internet connection. The app could download a wide selection of music onto the device overnight and provide a similar playback experience to what there is today. Or if piracy is a concern the app could just store 80% of the sound range and stream 20%.

The bottom line is that larger storage capacity is cheap, and could enable longer battery life and better use experience in the hands of a clever development team.

Tech Strategy – Change the Game

I’ve long been a sideline strategist watching the tech titans battle for supremacy, reading articles, taking classes and spending my commutes thinking about the way the tech-tonic plates (puns!) of the market are shifting under our feet.  Which doesn’t make me an expert, but it does lead to some wild ideas that an insider may not consider.

Which is a long winded way of saying, I have another idea for Microsoft.  You may ask, why are all your ideas about Microsoft?  Short answer: their core business is slowly eroding so they need to adapt.  On with the crazy idea, it’s time for Microsoft to change the game when it comes to customers mobile expectations.  Right now customers are used to technologically crippled devices, at least compared to their laptops. And the consumers adapting to these limitations directly erodes the value of the Windows OS value proposition, if you have to rely more on outside services and less on your device then your device matters less.

One way to change expectations is in regards to storage.  This is a three pronged attack against the current duopoly.  First, by pushing devices to market with large storage capacities at lower prices ( 256 gb for example) you grab headlines, look technologically advanced and hopefully shift customer expectations. This impacts your bottom line, but will erode your competitors margins significantly, and since they own a larger share of the market they lose more than you do.

Second, it changes the way a developer approaches building apps.  If it’s now possible to cache the 100 most popular pictures/movies on their device, then they can offer a better user experience via faster loads/transitions for big media files.  You’re letting your partners be creative and offer better product than other platforms.  This helps get your developer mind share back.

Third, and this ties into the last point about developers being able to create new and differentiated experiences on Windows.  You make the device a stronger platform which ties into Windows strength of providing a rich on device experience without the need for connectivity.

Fourth, for developing countries where mobile internet is still expensive, this enables your platform to serve them better by letting them utilize WiFi to load up on content instead of spending big money on connectivity.

Technology has advanced rapidly in the storage and battery arenas.  You can now buy 128GB SD card for less than $100, but Apple still charges $100 extra for half that.  It’s time to chop their margins and change the game.

Learning Ruby

The last time I tried to learn Ruby my Dad died.

Literally.

The two were entirely unrelated, but when I think if Ruby I still associate it with Cancer and dying. But since then I’ve also finished my CS degree and played with lots of different languages. And as I’ve evolved over time as an engineer I’ve wanted to find a a quick way to build an API or website, and while node/express has been straightforward I’ve always wondered how it compares to Ruby on Rails.

So with that in mind I’ve set out to learn Ruby again. I’m starting with the site RubyKoans (http://rubykoans.com/) because I saw it recommended by a rubiest as a way to transition from other languages.

 

__

Update:

My dive into Ruby evolved into learning Chef at work  to automate deployments for a private cluster and also creating end to end integration tests of that cluster.  Ruby is very fast and flexible, but a pain to try to use on Windows.  So I ended up doing all my work in a Linux vm and getting better with all the command line tools in the process, I’m not sure I’m ready to use Ruby for a side project but this work project really showed the flexibility of the language.

Of great important is that no one died.

MapReduce for Clearing Clutter

My desk is cluttered.  Some would call it a train wreck.  Some might even feel terrible about it being so cluttered.  I am one of those people.  But I’ve let it slide because of the priorities in my life; family, work, and personal health take precedent over battling a chaotic desk.

Of course, everything on it is there because I didn’t have time to deal with it in the first place.  But as I have transitioned out of school and into the working world, my life has become more routine, with more free time. And my desk has been taunting me.  It calls me names when I walk by, and earlier this week it started a war when it tried to dump a kitchen knife prototype on my foot.  The line had been crossed.

I dove right into the problem in ‘Naive Desk Clearing’ mode and soon felt overwhelmed.  I needed a strategy, and in a flash I decided my giant cluttered desk was a clustering problem.  Before me lay a giant pile of unstructured data.  There were distinct categories of stuff, each of which required a different thought process to deal with.  So trying to just iterate through the pile would have me context switching with each Desk Object, and thus wasting lots of time. And since I’ve been working with Hadoop at work, it seemed like an interesting way to tackle this real world problem. As they say, if all you have is a hammer, then every problem becomes a nail.

Abstracting a monoid from a sea of random stuff on a desk is tough, but seeing it as a clustering problem came fromthinking in terms of the attributes of the Desk Objects as what is being processed and not the Objects themselves.  Attributes -> Features -> Feature Sets -> Vectors -> K-means clusters. With my mind in feature set mode, it was time to do some mapping.

Mapping and Reducing the Desk Objects:

I start by mentally chunking out sections of the desk. Next, I process each chunk and score each object in the chunk mentally and put it into a pile based on its highest scored feature.  This is where my single processor humanity was at odds with MapReduce.  If I were a cluster, I would score all the objects in one chunk of Desk Objects while others scored the other chunks; then we’d switch gears, shuffle up our objects, do some clustering on each new chunk, then try to combine our chunks of data.  But I’m not a cluster of computers, so I put all the financial docs in one pile, kid’s art in another, electronics in another etc, in one step; and then moved onto the next chunk of desk space.

In the end it was more of an iterative approach because I couldn’t parallelize the process, but seeing the problem in terms of MapReduce helped me get past the overwhelming boredom that comes with a mundane task.

And pulled from the chaos was an old Seahawks belt, just in time for the Superbowl.

Developer Tiers

Through my time as a software engineering I’ve come to understand the craft of coding in a new light. As with the light bulbs over peoples heads in cartoons, it starts with an idea.

Which is to say it starts with one persons vision.  They then share that vision with other people that will help them build their vision, and if that vision is solid everyone will be developing the same idea.

Unsurprisingly different developers think of an idea differently, and I think it leads to tiers of developers that, all other things equal, separates the good and the less good.

The tiers come from looking at an Idea from different view points. First is the view point of how to implement an idea.  This is the type of stuff that shows up on job descriptions and is all about basic technical skills and ability to make something.

Tier two adds the ‘How to maintain’ the code base point of view.  In the rush to add features documentation and unit tests often get bumped but if the Engineer has the maintainers viewpoint they are still able to write code that doesn’t incur technical debt.  It’s self documenting, decoupled, re-usable and easily followed.

After that is the “How will the users actually use, or want to use, this software product”.  Sometimes the user is another service, sometimes it’s a consumer, sometimes it’s another developer.  At the end of the day it’s really important for developers to know who is using their product and be thinking about them. For any given piece of functionality there are N different ways to implement it, all with tradeoffs in speed, security, reliability, usability etc.

Keeping the User, Maintainer and Implementer viewpointS in mind while designing ensures that the implementation chosen builds the most present and future value possible.

The Microsoft Plan

Microsoft is changing. Everyone knows it, but no one is quite sure what will come out on the other-side when the transformation is complete. Having recently finished my finals and as I now get re-acquainted with my Xbox, I’ve been thinking about MS, Xbox and where the Redmond giant is going next.

“Services And Devices”

Which is fairly generic, in that they are saying they are going to sell time and stuff, which is the entirety of what you can sell in this world. Dig a bit deeper than that and it’s clear that the ‘stuff’ part is stuff that runs Microsoft software, and the ‘time’ part is selling Microsoft software as a service. So really, it sounds like they aren’t changing what they sell, just how they sell it.

Why are they changing? Simply put, their partners left them high and dry. From my outsider’s perspective, it seemed like MS partners were seeing a race to the commiditization (not a real word?), so they either played that game (Dell, HP) or they tried to use PC sales as a platform for other sales (Sony, IBM).? This left PC devices stagnant in a time when they could have been rapidly evolving. Then mobile hit, and MS had Windows Mobile, but it was built to partner specs, trying to give their partners a platform to build upon.

This is where things like TouchWiz and Sense were born. They were mostly annoying, laggy, and bug-filled attempts by device makers to not be selling commodity phones… while still selling commodity phones. The bugs, carrier pricing and lack of powerful hardware ensured they didn’t make sense for consumers. Then the iPhone happened.

You probably know what happens from here. Smart phone sales explode. Android shows up. Phones get cheaper. Smart phone sales continue exploding (it’s a long explosion). iPad mania happens, Android tablets show up. Now for $100 you get 80% of the functionality of your $500 laptop. PC sales are declining. Windows 8 misses the mark. People start grumbling that Microsoft is dying. Then Ballmer announces he’s stepping down and no one is yet picked to take his place.

The sinking ship’s captain abandons ship!

Awk-ward…

So where does it go from here? One idea is to borrow a few pages out of its competitors playbook and combine them with its playbook that got it to the top. Amazon Prime… Microsoft Prime? Well they have the prime cards already Image But more seriously, it’s time to consolidate all the subscriptions into one mega service “subscription.”

Microsoft Prime Lite:

Xbox Live Gold + Xbox Music + {Some sort of streaming service} + Office 365 + ‘lifetime’ tech support on purchases from MS store + Virus Protection + 10% discount at MS store + 50 GB Skydrive + Skype Premium.

Microsoft Prime Plus:

The same as Prime Lite, but lets customers pick from a list of partners for each service and have MS as the default. Call it an App Store for Services:

Pick one from each set {Xbox Music, Pandora, Spotify} + { Netflix, Amazon, Hulu Plus } etc.

Microsoft Prime Platinum:

All of the above, plus a new device (tablet, pc, smartphone) free every two years. Again with MS devices as default and partners devices available. Also with premium devices available for an additional fee.

Conclusion-> Consumers! Consumers! Consumers!

And with that, Microsoft could realize its plan to sell its software as “Services and Devices.” Or maybe Microsoft really just plans to copy Apple’s business model. Either way, they need to focus on the end customer first, and partners second, if they are going to claw back into consumer mind-share dominance.

 

Honeywords: A Follow Up on my Previous Post

After reading my previous blog post that included an overly annoying and slightly ineffective way to detect a password breach, my friend Chris from Casaba Security sent me an paper out of MIT that more effectively treated the topic with a very similar and much better implementation.

Link to MIT paper

Basically they suggest storing multiple passwords and the real password in a separate Authentication “Honeychecker” server. Then all password authentication attempts are routed to the separate server and when a malicious user is detected using a fake password, you can deal with them accordingly.

Their model of generating passwords for the user to select as their true password would most likely be met with harsh criticism in any consumer oriented product, but for a secure environment it would be more normal.  But it is necessary to implement their false password generator, and it improves security against users reusing passwords across different domains.

Having a ‘tough nut’ sounds good in theory, but any attacker sophisticated enough to be cracking passwords can easily modify their script to ignore extremely long passwords.  But it do like their idea of throwing the attackers through a loop with false passwords.  And the automated password cracking process seems like a great place to try to insert some counter-attacking code.  Password = “;DROP DATABASE”

A Random Way to Identify Malicious Visitors

password-crackingWhat I am about to describe is not perfect, only offers a constant and not exponential amount of more work to crack, and causes extra hassle for the user.  I am aware of that, but it was still an interesting thought experiment.

Main Idea:

A randomized password authenticator to help identify if/when the system has been compromised, and which visitors are malicious.  It does this by generating random similar passwords and storing the the true password along side them.  Then if a generated password is used on the site you know someone has been in your user authentication database.

More Words About It:

The typical user authentication cycle involves a user picking a username and password at account creation, and then every time they need to authenticate, they type in that username and password.  There are a number of issues with this method. The basic one being any password less than 6 characters long is trivial to crack with modern computing (Reference Article).  And while the simple answer is to force users to create longer passwords, this still doesn’t provide a great defense because users reuse their password across multiple sites.  At which point your authentication scheme is only as secure as the weakest website your users are replicating their passwords on.

Currently, if your website is hacked and the user information is leaked, all your users are potential open doors to hackers.  Their are a some good ways to ensure your encrypted passwords are hard to crack (Proper salting, bcrypt, SHA512), but as computing power increases or your information is sufficiently attractive, those barriers will eventually fall as well.  This is where some basic obfuscation can come in handy.

My proposal is fairly simple.  Create and store false passwords alongside the True password, then randomly select which password (out of both the false passwords and true password) is valid for authentication at the moment of authentication.  In this situation, even a users correct username and password combination would be rejected some portion of the time.  The level of rejection would vary depending on your need and acceptable user frustration levels.  In my scheme, the user selected credentials (I’ll call them the True Credentials or TC for short) would be correct 25% of the time.  So an user on average would take 4 or fewer tries to log-in with their TC.

Here is a sample of how this could be implemented broken down by steps:

Step 1: Credential Creation

Bob creates a new account.  With username=’Bobbers’ and password = ‘password1’

the user account name is stored as normal, and the password is stored in the password array of size 10 at a semi random location, here we’ll use a simple hash of adding the ascii value of each letter in the username and modding by 7.  So Bobbers = 66 + 111+ 98 + 98 + 101 + 114 + 115 = 703 %7 = 3.  So the TC ‘password1’ is stored in passwords[3].  The remaining slots in the array, 0-2 and 4-9 are filled with slight variations of that password such as  ‘1password’ ‘password12’ ‘9password9’ etc.

So now we have a password array filled mostly with junk.  We’re ready to try to authenticate.

Step 2: Credential Checking

The user comes to the site, enters their credentials and hits log-in. The server randomly generates a floating point number from zero to 1. A few cases can occur now:

Case A: If the random number is less than our selected randomized success rate of 1/4 or 25% or .25, then we calculate the position of the true password in the passwords array and check their submitted credentials against the True Credentials.  If they match the user is authenticated.

Case B: The random number is greater than .25%.  We now generate a random integer from 0-9 and calculate the true password position.  We’ll choose 5 for this example, which for us is going to be passwords[5] = ‘passwords123’.  The server compares the user submitted credentials against the username and ‘passwords123’.  If the user entered the True Credentials, their authentication request will fail and they try again.  But if the user happens to actually be a hacker who had access our user authentication data, they would be stuck guessing which password in the array is the correct one.  So they may end up submitting the false credential ‘passwords123’ thinking it is the true credential, or any of the other generated false passwords. In this situation, a hacker would have a hard time guessing the correct credential and my cycle through a number of generated false passwords trying to get into the system.

Case C:  In this case, it doesn’t matter exactly what our server is doing because it’s a thought experiment on detecting harmful visitors or a total breach of our user authentication information.  With this server setup, we could track what passwords are being submitted for each user.  If we notice a user keeps attempting a password we know was a false password generated by our server, then we can flag that account and restrict it’s access.  If we catch a system wide spike in authentication attempts that involve our generated false passwords, then we may be looking at a situation where our authentication data has been leaked.

At this point we’ve identified the potential threats in a few ways, and how to deal with them is up to you.

Adventures in Mobile Development

With my computer science degree almost completed, I’m starting a journey into Mobile development.  I’ve dabbled in Mobile Development a bit in the past but found documentation and tutorials not up to snuff for someone who was lacking technical skills.

So with my revamped skill set and a much deeper understanding of how computers work, I’m going to start simple and make a To-Do List application.  I’ll be chronicling my work here.

I’ll start with Android development, move into iOS and eventually Winows Phone.