Centare Planning Poker App

Are you still using cards for your planning poker sessions? Go mobile with the Centare Planning Poker app. Create a virtual table for your planning poker session and invite other team members to connect with a simple table code. Host a table and email the code to other team members. If you’re joining as a participant, just enter the table code and join the session.

]]> http://www.centare.com/centare-planning-poker-app/feed/ 0 http://www.centare.com/case-study-gapnsnap-app/?utm_source=rss&utm_medium=rss&utm_campaign=case-study-gapnsnap-app http://www.centare.com/case-study-gapnsnap-app/#comments Fri, 10 May 2013 16:25:43 +0000 William Welbes http://www.centare.com/?p=10574

The Client

gapNsnap

The App

Our Solution

Be sure to learn more about the man heading up Centare’s Madison-based efforts.  Eiring’s profile provides insight into his role at Centare, his passions outside the office, the iconic Milwaukee Brewer he strives to emulate and several other interesting tidbits. 

Weinand, who was a member of the Charger team in 2006-07, enjoyed the robotics program so much that he now volunteers his time as a video and web adviser.

“I was involved with this program my junior and senior years at Sussex Hamilton,” says Weinand. “Being a part of Team 537 was such a wonderful experience. It truly shaped the person that I am today.”

For Inspiration and Recognition of Science and Technology (FIRST) is the mission behind the annual robotics competition. It draws teams from the U.S. and all over the world to solve engineering design problems under intense deadlines. The FIRST World Championships are considered a high-tech spectator sport that involves real-world teamwork and mentoring from industry experts.

Weinand was at the U.S. Cellular Arena in Milwaukee on March 23^rd when the Chargers placed 12^th out of 57 robotics teams at the Wisconsin Regional event. The team also won the “Gracious Professionalism Award.” In early March, the Chargers earned the “Regional Chairman’s Award” for a third time at the Lake Superior Regionals in Duluth, Minn. These recognitions led to an invitation for the Chargers to compete in the FIRST World Championship in St. Louis, April 25 – 27.

Why Behavior Driven Development?

The term “Behavior Driven Development” aka BDD was first coined by Dan North. The initial reason for the idea behind this development practice was to support Test Driven Development.

In recent years, the discussion on Behavior Driven Development is about the fact that it helps define system behavior at a little bit higher level (starting with business goal) when compared to Test Driven Development where the system behaviors are typically defined at a lot more granular level (classes or functions).

BDD encourages team collaboration when defining the behaviors. BDD helps the teams (especially when they are agile) to be focused on the business value of the feature being developed.

How is Behavior Driven Development done?

Typically the business reason will be defined by the Product Management in this format.

As a “user”

I want a “feature”

So that” I get some value”

Now all the team members who will be working on the business reason will get together and come up with all the behaviors that will be defined in a “Given.., When.., Then..” format.

Given some initial context,

When an event occurs,

Then ensure some outcomes.

This activity when done as team will enable the team members (both technical and non-technical) to collaborate and discuss many possible scenarios from various angles and expertise levels. This will in turn help the team to come up a good set of behavior definitions (acceptance criteria) and flesh out the details.

A made-up team in action with BDD:

Let’s assume that Paul ProductManager gives this requirement in the business reason format to a team that comprises the following specialties – (Arthur Architect, Brenda BA, Dave DBA, Dylan Developer, Tabitha Tester, and Ursula UX). This team is practicing Behavior Driven Development.

Business Reason:As a new user to this application, I should be able to “Create Password” so that I can login to my account using that password.

The team looked at the business reason and plan to flesh out scenarios in the Given, When, Then format. Here is the conversation. They also request Paul ProductManager to be present in case of clarifications.

Ursula UX- Before going into defining the acceptance tests, what do you guys/gals think about this business value (so that I can login to my account using that password) in the business reason? I believe the value should be a bit more substantial than just allowing the user to login.

Arthur Architect – I agree with you on the business value. Why does some one create a password in the first place?

Dave DBA- If I am a user, I will create a password for my account so that no one will be able to access my information except me.

Arthur Architect – That seems like “the user is concerned about the security of their information”.

Tabitha Tester- What do you guys think about this revised business reason?

Business Reason:As a new user to this application, I should be able to “Create Password” so that I can feel secure about accessing my account information in the website.

Brenda BA- This is great, but still this requirement seems incomplete to me. Let’s start by writing an acceptance criteria and see where we can fill in the gaps.

Given the user tries to create password

When the user enters password information

Then the user will be able to log in to the account with the newly created password.

Dylan Developer- The information for “When” is not clear, what should the user enter here?

Paul ProductManager- Oh, yeah, the user can enter letters, digits and special characters.

Arthur Architect- What set of special characters are we going to allow? How about spaces?

Paul ProductManager- Hmmm, let me think! Why don’t we include just the special characters that appear in our keyboards above the digits?

Ursula UX- I will get that information for you. So that will be !@#$%^&*()

Brenda BA- That’s great information. Let’s have a second attempt.

Given the user tries to create password

When the user enters letters, digits and the following special characters!@#$%^&*()

Then the user will be able to log in to the account with the newly created password.

Tabitha Tester – Are we going to allow both upper and lower case for alphabets?

Paul ProductManager- Yes, I think we should allow that.

Brenda BA- What should be the length of the password?

Paul ProductManager- The user should enter at least 8 characters.

Brenda BA- Should we restrict the maximum length?

Dave DBA – Whatever we define for maximum will be the field length for Password in the database table. Right now, the password field length is set to 20.

Arthur Architect – I think that is more than enough for a Password field. We don’t want people entering ridiculously long passwords.

Tabitha Tester- Do you care about the character order in which the user should enter the password? For example, the user should enter alphabets followed by digits followed by special characters.

Paul ProductManager – Good point. I haven’t thought about it. Do you guys/gals have any suggestion on best practices?

Arthur Architect – There is no best practice, but more and more organizations enforce users to have a “strong” password.

Dylan Developer – I have seen organizations require users to have at least one uppercase letter, one or more lowercase letters, at least one digit and at least one special character.

Brenda BA- Let us try this again.

Given the user tries to create password

When the user enters letters (A-Z, a-z) and a digit (0-9) and a special character ~!@#$%^&*()

And the password length is at least 8

And the password comprises of at least one upper case letter, at least one lower case letter, at least one digit, at least one special character

Then the user will be able to successfully create the password

Ursula UX- Paul, you don’t care about the order of the character entry, right?

Paul ProductManager- I think we should make the user enter a strong password but the order can be of their choice.

Brenda BA – Great, I think we have the next version.

Given the user tries to create password

When the user enters letters (A-Z, a-z) and a digit (0-9) and a special character ~!@#$%^&*()

And the password length is at least 8

And the password comprises of at least one upper case letter, at least one lower case letter, at least one digit, at least one special character in any order

Then the user will be able to successfully create the password

This conversation can go on, but you get the gist of the collaboration, right?

—————————————————————————————————————–

Now the same requirement is more defined and clear. The collaboration among all the team members with their product manager helped them define comprehensive behavior.

This way of defining the requirement can be done by any non-technical team members- especially the product owners, business analysts, non-technical test specialists, SME’s etc.

Tools to consider:

This behavior-driven, domain-specific language (Given, When, Then) in which the requirement is defined is sometimes referred to as “Gherkin” (Gherkin is initially coined to represent the language used in Cucumber tool).

There are a variety of open source tools that are available to support this development. Some of the popular ones worth noting are SpecFlow, Cucumber and JBehave. ‘SpecFlow’ supports BDD for teams that do .Net development and can be very well integrated with Visual Studio. ‘JBehave’ supports BDD for teams that do Java development. There are multiple open source tools available apart from what I have listed above that support BDD.

All these tools will allow the user to define the business reason and the corresponding behaviors in the “Given, When, Then” format and that can be converted to test structures easily.

Here is the screen shot of how the feature is represented in SpecFlow.

Here is the list of test methods created in SpecFlow by the “Given”, “When”, “Then” lines in the behavior definition.

Impact on Programming:

This is a great starting point and helps the programmers to outline some clearly defined unit tests around the behavior. Programmers will be able to effectively design code by writing tests based on the behaviors. BDD enables the programmers to write tests first easily and thus support Test Driven Development (TDD).

Impact on Testing:

Teams can start writing automated tests based on the defined specifications almost immediately with the help of tools. This helps in growing the team’s automation suite almost immediately. Early automation realizes the value much sooner than tests that are automated after feature completion. This will also aid testers in spending more time on exploring the application rather than spending time on manually testing expected behaviors.

Benefits of BDD:

1. Writing behaviors in the “As a.., I want.., So that..” and “Given, When, Then..” format is simple and is a natural language. This enables the collaboration among technical and non-technical members within the core team and outside team members.

2. It helps the team understand and focus on the business value of the features that are being developed.

3. Using some of these tools will ease the teams into automation by creating shells for steps of the defined behaviors. The shells can then be expanded to develop tests. They encourage small, easily maintainable chunks of automation.

4. It enables the programmers to perform Test Driven Development, which is widely considered a best practice.

5. Living and up-to date documentation for the software is a certain advantage if tools are used to write tests. The business reason and behavior will be included as part of the code structure.

Having conversations among the team members about the behaviors is more important than capturing the behaviors which is more important than automating the behaviors. – Liz Keogh, ALM Chicago 2013

Looking ahead in to the future: Jeff Goethelf in his recent book “Lean UX”, talks about getting the market feedback as part of behavior definitions/assumptions. It seems like a powerful technique that will help validate the business assumptions and that appears to be a great next level in defining behaviors.

The focus of this writing is on the appropriate amount of unit test coverage in legacy code.  As a definition of legacy code, I defer to Michael Feathers’ description: code without tests.

Common questions about code coverage are how much is enough? Is it worth adding tests to legacy code already in production? How do you prevent gaming of the system to meet arbitrary coverage requirements? How do I get started? I take the stance that a development team should aim for 100% and no less. I will address all of the above questions in what follows.

How much is enough?

Legacy code is often difficult to maintain for many reasons. The code may be tightly coupled to external dependencies (file system, web services, etc.), hard to read due to cryptic or poorly thought out method and variable names, and often without a set of automated regression tests. This software needs care and feeding until the end of its useful life. Brittle, hard-to-read code becomes more difficult to manage with each new developer making changes.  As professional developers we are tasked to go in to the code like surgeons, cut cancer off the heart of a dying patient, and leave no scar. This is scary work without proper tools and a good safety net.

For the reasons above I am on the side that 100% coverage of code you maintain is necessary.  Only a rare few of us get to work on projects that will be thrown away in two months (such as a one-time rock concert promotion website) so for those few developers, ignore the rest. For the rest of us, what I mean by 100% code coverage is 100% of the logical paths through your application that your team maintains should be covered by a suite of automated tests.

If you feel you can have maintainable software with less than 100% coverage I ask you this: which logic is important enough to put in production, but not important enough to be under test? In a 1 million-line application, which 200k are not worth testing if only 80% coverage is okay?

Is it worth the costs?

Let’s look at how we spend our time, without test coverage, by accounting for the time spent on the following activities of a feature addition without well-written, unit-tested code:

Reading and understanding the code to find the affected code

• If you had good tests fully covering the logical paths you would have real examples of how the code is used. Good test names give you documentation of the code on which it tests (ex: DividerMethodThrowsDivideByZeroExceptionWhenZeroIsInDenominator(). )

Modifying the code

• If you had full coverage you could make safe, small, and incremental changes letting you check your work as you go.

Manually testing

• If you had full coverage it would greatly reduce the time spent manually regression testing

Dealing with bugs found in production from the unintended downstream effects of the change. Include the time spent by your support staff.

• If you had good tests you would find bugs while developing reducing the bug’s cost and impact. 

Multiply the number of hours you calculated above by every change to the application and double the hours for less domain-experienced developers. This will start to look like a lot of time.

If there were good tests in place covering 100% of your application, you can be more confident your changes will not have unintended consequences because you have a safety net (the tests).

100% coverage requirements cause system gaming

Common arguments here are:

100% coverage will just cause developers to write tests that meet this requirement and game the system.

• 100% coverage is an aim for quality, not something on which a developer’s bonus should be tied

You can achieve full code coverage without checking the output in your tests.

• True, but there is some value in having tests that don’t check output and just exercise the code. Tests are more valuable if they actually test.

100% coverage does not mean you have good quality tests.

• While this is true, not having good tests is usually a result of developers lacking skill. Developers lacking skills also write bad production code

100% coverage does not mean all cases are covered.

• Again, true. Having all of the happy paths covered would give you 100% coverage, but this still has incredible value in that you know if a happy path is broken if a test fails.

My baseline assumption is that your developers write good tests when they write tests and have the skills and tools to do so. A few attributes of a good test: they are well-written, self-documenting, small, test one thing, and check for one result per test. For a good reference on writing good code and good tests, Clean Code by Robert Martin is a great start.

Another argument is that there is little return on investment to build tests for software where tests did not exist before. Assuming you are now a test-driven development shop, (which you are, aren’t you?) then every line of code you write is first covered by a failing test. As you maintain your existing code base, you build tests, which eventually will approach 100% coverage. I am not advocating for sending a team of developers off for a month to write tests for existing and functioning production code. Write tests as you go. Add new tests while you are adding new features and fixing bugs.

The goal of 100% coverage is to cover all logical paths and functionality in your software with a test. The number by itself is meaningless. 100% coverage should be a team goal and a challenge to the developers to build highly maintainable code. The business pays quality, fit-for-purpose software and aiming for 100% coverage is a way to deliver that.

How do I get started?

To eat an elephant you must do it one bite at a time. To get your code base to 100% coverage, you need to do it one test at a time. By aiming for and maintaining this high standard you can get to 100%.

Start with the feature or bug fix you are working on now. Wrap the code you intend to change with a test to verify its output in the current state. For example, if you have an adder method accepting two integers as parameters, wrap it in a test to call the adder method and check that the output is truly the addition of what you passed in. After the new, automated test passes, refactor the code to be simpler and more readable. Next, write a test for the new feature or bug fix you have not yet written and verify it fails (remember, test first). Finally, write just enough production code to pass the test. Refactor the code, as needed, ensuring your tests still pass. Start with happy path testing and add edge case testing as needed. Perhaps you find an edge case that the current code cannot handle. Take the opportunity to discuss the edge case with your team and decide what to do.

Another technique to try: use the code coverage tools (either baked in to your IDE or a plugin) to see what methods and logical paths are not covered by unit or integration tests and create new tests to bring up the number. Using this technique I have found unreachable production code so I safely deleted it.

There will be cases where it does not make sense to cover the code with a unit test such as generated code or third-party libraries and frameworks. As a team, agree what these cases are and exclude them from code coverage. Again, the point is to get 100% of your logic covered and functionality tested. Work with the tool to define full coverage to keep the 100% mark meaningful.

In closing

I challenge you to follow the Boy Scout rule: leave every line of code you touch in better shape than you found it. Write tests for your changes and code you affected and leave them as a gift for the next developer. By continually taking steps to make your code better you can achieve 100% logic coverage in your legacy applications.

Literature:

• Working Effectively with Legacy Code
• Brownfield Application Development in .NET
• Clean Code

Tools:

• Code coverage tools either built in to the IDE or as a plug-in
• Resharper – Visual Studio refactoring plugin
• Ncrunch – Visual Studio real-time unit test runner plugin
• Typemock Isolater – unit testing framework specializing in legacy code mocking
• Microsoft Fakes– another unit testing framework specializing in legacy code mocking

In this post I am going to demonstrate the process of deploying a simple ASP.NET MVC 4 application to an Elastic Beanstalk application. Note that while this example uses .NET, Elastic Beanstalk supports PHP, Java, Ruby, Python and more.

More on the Value-Prop

Skip this section if you are already familiar with the value of Elastic Beanstalk.

Some of the key values/promises of deploying web applications to the cloud are seemingly unlimited scaling, robust high availability configurations, the ability to stop caring about infrastructure, and other things along those lines. These are all great ideas and definitely feasible, but not always as easy as they may seem. Using AWS as the example, if you wanted to deploy a web app with pretty solid reliability, you would need to create and manage 2-4+ EC2 instances across multiple Availability Zones, multiple load balancers to tie them together, have the intelligence to scale your number of instances based on load, and then manage all those things long term. Security updates, backups, deployments, credentials, etc. It gets messy. Elastic Beanstalk is an attempt to alleviate some of that complexity by automating a majority of the plumbing. the highest level object in Elastic Beanstalk is an application. You send versions of your code to the Beanstalk application which then takes care of creating the EC2 instances necessary to run your code and deploys it to those instances for you. In addition to creating the instances, you can configure it to monitor various metrics such as CPU load, and automatically create new EC2 instances on the fly and add them into the cluster. Thus the load balancing, server creation, deployment and scaling are all handled in an automated fashion. Pretty cool.

Climbing the Beanstalk

There are several ways to configure Elastic Beanstalk. AWS has a solid web interface, a powerful API, and numerous 1st and 3rd party tools that use that API. My examples leverage Amazon’s own AWS Toolkit for Visual Studio in order to illustrate how seamless the process can be for .NET developers – but know that you can achieve all of the same results by using the web interface. The concept is what’s really cool here, not necessarily the specific implementation. Before reading further, I suggest taking 2 minutes to read through this brief AWS doc page for some terminology explanations.

I’m just using a little dummy application int he examples below, but I would also suggest giving this a shot with any old web application you have laying around.

Creating the Beanstalk Application

The first step after installing the AWS Toolkit and getting your ASP.NET project ready to deploy is to initiate the AWS Publish process.  The process for this is comparable to using the Web Deploy functionality that has been around Visual Studio for a couple of years. Right-clicking on the web project will reveal a nice new menu item right under the old Publish option.

Once into this process you will be prompted for your AWS security keys (which you can view via the AWS web interface under [Your Name] -> Security Credentials). Now that the AWS Toolkit knows which account it needs to be connected to it will start going through the process to actually create the Beanstalk application and get the deployment going. The first thing it needs to know is what type of deployment we are doing. In this case it’s a Beanstalk application (but remember that the AWS Toolkit provides access to much more than just Beanstalk).

After indicating that we’re looking to create a new Beanstalk application it will ask for some other basic information such as the Name of the app and a default URL to use. Those are self-explanatory. A couple steps in the wizard later we specify some of the more important details like what technology stack should be used and what type of EC2 instances Beanstalk should be creating behind the scenes. Beanstalk will start be creating one instance (a Micro instance in this case), and then will create additional instances of that same type as needed per the auto-scaling configuration.

After all the required settings are filled in the “Deploy” button will become available. Clicking that will build a deployment package (in the same format as a traditional Web Deploy) and begin the process of actually setting up the Beanstalk application up in the cloud.

So within just a few minutes we’ve instructed AWS to do a number of very powerful things. With the settings we configured right within Visual Studio, AWS has now:

• Instantiated a Windows Server 2012 EC2 instance ready to roll with IIS 8.0 and MVC 4
• Created and configured a load balancer
• Deployed a custom ASP.NET MVC application
• Created an HTTP-friendly “security group” (~firewall)
• Created DNS entries in the Route 53 system
• Prepped an auto-scaling group (more later)

Those are all tasks that would need to be done manually (for the most part) if standard virtual machines were being used instead of Beanstalk. They all done automatically without ever logging into the AWS web interface or remoting into a server somewhere.

Then What?

I don’t know, take a break maybe? Do some pushups? I glossed over a number of details, but a lot happened there with very little effort; and all other things being equal, getting good with this approach has the potential to save valuable time throughout a development project and even more time during the ongoing maintenance period of an application.

Additional Topics

I skipped a couple of important points while going through that example in order to illustrate how simple a basic case is. These topics below don’t add a ton of extra effort, but there is a slight learning curve.

Databases

Short story: Amazon RDS (Relational Database Service) makes it very easy to incorporate a relational database into a Beanstalk architecture.

RDS can take the form of MySQL, SQL Server or Oracle, so chances are you should not have to modify your application’s code in order to interact with it. You just treat it like a another database server. I don’t know why, but when using a Windows/.NET Beanstalk application, you need to manage your RDS instance separately from the Beanstalk application. That doesn’t entail that much more effort but it is a minor inconvenience. With non-Windows Beanstalk applications, RDS configuration is included within Beanstalk itself when using the web interface. So it saves a few steps, but the net result is essentially the same.

Monitoring and Auto-Scaling

Exactly what it sounds like. Since Beanstalk dictates the AMIs of the EC2 instances that it creates, it can do some cool monitoring and even take automated action based on that monitoring. Going back to the AWS Toolkit for Visual Studio again, views and configuration screens for this part of Beanstalk are also readily available.

Auto-scaling of course goes a step further and manages the number of instances running in the application based on various load-influencing metrics.

Cost

The Elastic Beanstalk service is actually free to use. All costs are incurred by the underlying EC2 and RDS instances, storage, DNS, and bandwidth. The Elastic Beanstalk pricing page has a couple of useful tables for what various example scenarios would cost per hour/month.

Conclusion

Elastic Beanstalk is a powerful technology and the fact that it can be tightly integrated into the standard development environment and process for .NET developers is a big plus. It doesn’t solve every problem though. For instance Beanstalk applications cannot be scaled across geographical regions, only Availability Zones. So you would need to go beyond this basic configuration for a maximally robust HA architecture.

My main takeaway and incentive to continuing looking into Elastic Beanstalk is simply that it seems substantially more efficient to walk through the exact deployment process described above than it does to spin up a Windows Server, install IIS, configure ASP.NET, configure a load balancer, setup permissions, and XCopy deploy packages for every project that I work on.

According to Microsoft, champions are chosen for advising Microsoft users and for sharing practical industry experience on how to improve software projects.

“Dan has constantly delivered quality feedback and diligent reviews in his work and interaction with the members of the Microsoft advisory board and our development teams,” says Grigori Melnik, principal program manager for Microsoft patterns & practices. “Dan’s broad industrial knowledge and deep technical expertise make him one of the best advisors I’ve ever worked with.”

This is the second P&P recognition for Piessens since he began working closely with the software giant in 2005. Just this year, Piessens worked as an advisor for several Microsoft projects including the CQRS Journey and Enterprise Library Integration Pack for Windows Azure.

“One of the goals of the P&P team is to take the never-ending stream of new technology from Microsoft and translate that into workable solutions in different industries,” says Piessens. “I offer perspective on real world situations and relay user feedback on their approach. My intention is to improve and work until we get results.”

Piessens joined Centare in the fall of 2012 and has been in the software industry for 12 years. He is a graduate of Marquette University High School, UW- Milwaukee and Marquette University.

“Dan has been instrumental in guiding our clients through multi-layered technical issues,” says Andrew Hall, director of consulting at Centare. “In fact, Dan accepted a job with Centare over Microsoft, so it’s tremendous to have him engage with us.”

The Client

Positively Pewaukee

Positively Pewaukee is an award winning non-profit organization dedicated to making Pewaukee, Wisconsin a premiere destination and a place people love to call home. A member of the Wisconsin Main Street Program, Positively Pewaukee fosters business growth and partnerships in the community, produces events, establishes community connections and helps beautify the downtown. Comprised of both staff and volunteers, Positively Pewaukee has a great impact on the Pewaukee community.

The App

Explore Pewaukee is your mobile guide to all of the places and events that make Pewaukee great!

Get plugged in with the latest information about Pewaukee events and happenings. Find out about the next festival, water ski show, or community event. Be notified of current and upcoming events right on your device. Looking for a place to eat? View restaurants on a map or in a list and filter by type of cuisine. Simply tap to call or view the website for more details. Searching for a place to stay or shop in Pewaukee? View a list of the locations and drill down for more information. Discover new spots each time you use the app.

Looking for more information about Pewaukee? Tap the “more” section to view information about our community, government entities, and community groups. Check out the latest photos from around town in the photo albums.

Our Solution

Explore Pewaukee demonstrates Centare’s ability to deliver an end to end solution; from app design, implementation, back end data, services and administration.  Centare created an extensible platform that provides the client with the ability to easily maintain and update app data.  The app design provides a very polished and professional look and feel and an experience that draws the user in.  Centare’s breadth of expertise and experience enables us to deliver complex mobile solutions that are well designed and fit for purpose.