Source Control saves time and complexity

Using source control effectively helps in a number of areas. It gives you a concise history and flow to your own work; and allows you to collaborate on shared artifacts with others.

Docs

As an overview source control for code tackles the same over-arching problems that arise when collaborating on any document. Lets say you are working on a presentation or document with someone and you make changes. When you send them that version of the doc, it may be different than what they have changed. Maybe you have changed the same part of the doc. How do you resolve these changes so you know you both have the 'latest version'?

Sometimes the file name is changed, or you can look at the date edited, or comments are used and later rolled into the master source. No matter what you do, there will be a manual sync and review to make sure the last version is the 'good one'. This is error prone, you have been there!

Lately, with cloud based documents like gsuite or office365, changes are saved automatically to the source, and you are able to see what other users are viewing or editing. This certainly helps, but I have found users are hesitant to believe this is happening behind the scenes.

Code

How does this work for source code used in software application? There are potentially hundreds or thousands of files for source code and the configuration to run the application. Artifacts are everywhere.

I have actually worked with collegues where we would zip up all our files, and make changes one at at time. This is painful. Early source control tools like SourceSafe and CVS have this cenralized view of the source. A user locks the file for changing, makes the changes, and then everyone can sync  up with that. This helps, but caused issues as specific users 'locked' the file and it was able for any revision until that user was finished. What happens when your manager accidentally checks out all the files and leaves on vacation? Or someone gets walked out the door when they have files locked to their specific account? It happens.

Distributed code bases

A decentralized code-base solves this problem with one specific trick. Instead of everyone working on the same document and managing their changes, everyone gets their own copy of the source, and the changes are merged together in the end.

When using git, due to its distributed nature, you have a repository locally, and a remote repository. Why both? Its important to have a local repository to know what you have changed, and be able to see your changes in respect to the remote. Remember that its really a copy of that remote that you are changing, and then you are merging your changes in the remote so that other users of the remote can see those changes.
This way of making changes allows you to manage the changes, and how and when they get merged to the branch everyone is using.

Git Commands used often

Getting the code to your machine

• git clone
• cloning a repository will take the version of the code when you clone. Any changes to the repo after that will not automatically show up in your local copy until you pull those changes yourself.

Making changes

• Use your favorite editor to make a change to any file. Its a good idea to make changes that are small, and focused by the feature being changed. the context of this change is best contained in an issue that you are able to track. You can try to keep all the changes in your head and try to remember everything, but that amount of complexity will get the better of you over time. Keep your changes easy to track and understand.

Seeing your changes

• git diff

Committing changes

• git commit 

Pushing your changes to the remote

• git push

Getting changes from the remote

• git pull
• see where the remote is with 'git remote -v'

Workflows

Git supports different workflows, and depending on the team they are all valid.

1. Single trunk 
1. integrate often, needs feature flags, pairing and team work
2. Feature branching - integrate when needed
1. Good for team not in the same room and when contributors aren't on the same schedule

Git Commands for workflow

• git checkout
• git log

Checking out

When doing a checkout, you are declaring that you are making some changes. Add some context to this so when viewing the log of changes, you know what those changes were for. For example, a bug comes in to change the color of a button. Make an issue for that, and lets says the issue is first issue on this. This fits into a UI theme, or better yet a more descriptive feature theme, and has an entry in your favorite issue tracker. the resulting command would be:

• git checkout -b LOGIN-1_set_button_color
• translated: Checkout a branch related to the LOGIN-1 issue. Add the further description to give the git log more readability

Branches
Branches are really handy for isolating changes and ensuring that a single branch has what you are intending to put into an environment for testing, or to your production server for your users.

1. link to issues
2. checkout with a new branch, and describe it correctly. When you look at the master branch you can see all the changes that everyone made.

 This is the same output as 'git log'

Deploying and hotfixes

• if deploy from master: use a develop branch, make a branch for a release, merge to master when ready

workflow tools

Commit hooks are handy for things you do anyway (unit test, static/dynamic analysis). Before you commit your changes and push to the remote repository, you will probably run your unit tests, and check your formatting with the standard your team uses. This can be a number of commands, and you will probably do them in the same order each time.

• add pre-commit hooks for running these commands, so if the tests fail, or the formatting is off; the commit won't happen. Its nice and automatic!

Wrap it up

Using source control effectively is more than sharing changes with the people you work with. For developing it allows a further level of collaboration and adds some handy tools to your workflow to reduce error prone operations from more manual processes.

From Big Idea to Product

This is a story of a big idea. It's where a group of people who want to make technology that can turn into a business and generate money and thus, feed people and their dependents. In this story the participants have worked in technology start-ups; so they have got past the grand ideas of getting rich quick, and now just want to make a living with a business they can call their own.
We have all read about this happening, so lets go through an exercise of making it happen! In this story I work with my trusted business partner Liz. She is hyper organized and good at business. I am neither of those, but can make software; so we make a good pair.

Liz phoned me up the other day...
"I met someone that works as a cashier, and they have to carry around this cash register all the time. The shop they work in want to expand, but these registers are expensive. Thing is, all it does is add some numbers and print out a receipt. I thought, a software app could do that; and it would be easier for them to use their phone instead of the big register. Also, if it works and is cheap to buy, they would use that instead of the register."

Then I thought: don't all stores have this problem? If we make a 'mobile register', then we could disrupt this entire cash register space!

Understanding the problem is the start of solving it

Ok, so from that we have some things forming up about the product definition; but it's clear we need to know more about this opportunity before we start making anything. What's the value to the user, and the buyer? Is this a big market or small, and who would pay for this? If they would, how much would they pay?

Using lean canvas or the venture process, we can go deeper on the understanding of the possible opportunity.

Our Hypothesis: People buy stuff, so the need to cash them out seems pretty real and constant. If the register is expensive and we can build a cheaper one; then small companies would buy them to save money. presumably any company would for the same reasons.

My response to Liz: "Ok, this seems feasible at a glance, but need to know more. Let's find some prospects and see if this could work."
Liz went back to her original retail friend Chris, and asked if he would like a cash register on his phone, instead of carrying the old clunky one around. 'Sounds great!' Chris said.

• This issue with this 'ask' is that Liz was immediately selling Chris on the solution, and that sounds good. What is Chris going to say? "no thanks, I love ol' clunky!".

Perhaps a better approach would be investigate why Chris would trade his old machine for the phone or why not. Asking why would get to the problem at hand, and a good way of finding that out is investigating what they do now to solve their cash-out problem.

What do they do now?

If the problem is key, and the solution is valuable, the prospect is doing that job in some way. What we are hoping is that their methods have pain that they want to get rid of, and see our solution as a way to get there.

So, what does Chris do now?

1. Carry around clunky, its heavy.

2. Clunky adds numbers, but I need to look up the currency conversion in the daily currency table and the tax rate of the buyer. Mary wants the totals in CDN dollars.

Ok, who is Mary?

"Mary is the manager of the store. I need to send her the totals when I'm done with a shift so she knows the totals."

It turns out Mary the Manager is a persona we need to care about; since it's Chris' job to report totals to Mary. Lets talk to Mary about her role and these 'Totals'.
Mary responds with:

'Ya, I need to settle up every day and send sales totals to my owner, and I also need the totals to get my inventory status'

This info is gold! Mary need 2 outputs from the register experience. The sales totals of the shift, and the amounts sold so she knows what inventory is left, so she can order more or not, and see what is selling.

Now we have 2 Personas; a User (Chris) and a Manager (Mary), and there was also mention of the Owner. We have to care about Mary since correct reporting from Chris its a measure of doing his job correctly. If we make Chris a success in Mary's eyes; he will use our tool. If Mary is able to provide great reporting to the Owner, then she is a success, and she will use our tool. So, in reality, we need to make the tool for the Owner of the store, and then Mary, and finally Chris. This may seem counter-intuitive since Chris is the one using the tool most often, but its the value that the tool is able to generate that pays for it, and the Owner is the persona that needs the convincing.

Personas and Problems

• Chris the Cashier - adding numbers, calculating/adding taxes, converting currency, reporting sales to Manager. time to cash-out customer
• Mary the Manager - calculating sales, reporting on sales and inventory used, reporting to Owner
• Sue the Owner - needs accurate reporting of inventory and sales to determine health of the store.

Ok, this seems to be making more sense; but one big question still needs to be answered. Who is going to buy the product?
Would Chris pay out of his pocket? Would Mary expense it for Chris? Does the Owner need to OK that purchase, or does the Owner make all the decision making on the purchase? At this point it could seem like a good idea to pitch the Owner to buy the product, and convince them that the managers and clerks in their stores need mobileCashier (we just decided to call it that).

This is probably too early to directly sell to the Owner; as the first contact from the Owner's point of view is getting sold on something they haven't heard of.

User Personas influence Buyer Personas

What would be more influential is to have Mary tell the owner that they are trying a new product that will save time and money. If you were the owner, what would you listen to? If Mary sees value in it, then she will pitch for it, and if Chris is making more sales because of the efficiency gains from the app, then he will tell Mary about it.

Persona Key Problems

So, this is only going to work if Mary proves to the Owner that mobileRegister saves time and money, and thus increases sales throughput. From this, we can ascertain that a Key Problem for the Manager Persona is reporting on sales and inventory. If we don't build that, Mary won't see the value. But wait, you are still making Chris carry around the old register? Sure, but the sales and inventory report is what is really needed in the end. We can address this key problem by making sure when Chris uses the app; the data generated ends up in the reports to Mary. It might even be enough for the MVP to forget about the manual currency and tax calculation and concentrate on the report for Manager Mary.

Domain Problems

Regardless of the users involved, there are rules about the domain of cash registers that we need to satisfy, and these will become requirements of our solution.

• Numbers arithmetic of adding, getting percentages and totals.
• Currency - this changes, so how do we get the latest exchange rates? How accurate does that have to be? Daily, Hourly?
• Taxes - this changes, but only annually. How do we get updates on the tax rules for any country that the user is in? How often will we sync our rates with the reference. What is that reference?

Checkpoint for Market-Product fit

We don't have anything resembling a product at the moment because we are still figuring out the key problems for the Domain and the Users in the Market. What we are trying to identify is what key problems that the user will need, and need so much that they, or the persona identified.

Go for a v1?

How far does this research go before starting to build? This is a tough nugget. You need to know you have a Market that has users and money to pay for a possible solution. We could spend more time analyzing this, but it might be more effective to build a simple version so we can go back to our prospects with something that is showing that we can solve their problem. Otherwise we could tire them out with our research questions.
You might find users that are totally passionate about what they do; but most people are there to get their job done.
This set of problems, personas and jobs to be done is a key deliverable for understanding the market and how our solution is effective at solving key problems. This understanding will evolve over time as we learn more, so it's never done, but there seems to be enough there for our current needs. We really believe there is a need. There is, but perhaps the point of sale space is a bit crowded (it is), but we think we are going to build a better mousetrap.

From this point, both Liz and I have our current mission.
I need to

• start on a possible architecture that will allow the user to do the cash register thing over the web on a phone
• do reporting, this sounds like a desktop spreadsheet thing
• find out about the data needed for currency and taxes, can I easily import this, and can it be automated

Liz need to understand the basics of the business

• Cost of getting a customer and more customers
• Understanding the jobs to be done, and how big is the possible market of people that do this?
• A basic forecast to understand what can be sold, for how much, and how many customers are needed to pay the two of us

Time to make something

We think we are onto something here, so we are going to build what we consider to be a MVP to test out this hypothesis and see the results. How do we do this? We have a good idea of what is required, but its still in a very informal format. We need to understand how the user is going to use our solution, and what problems from the domain need to be solved to show that the product has value.
Understanding these Problems will form our Strategy for building this solution, and the company that surrounds it. It's a key deliverable, for sure.

Lets go for it

We are going to take the next step. We do this by formalizing the behavior of the User in Stories, and conversely, understanding the Requirements of the solution to make it all happen.

• User experience is a combination of user stories. we validate the story with Acceptance Criteria. 
• Domain Rules need to be formalized so they can be implemented.

 but that will come in a following post... till next time!