Being an effective developer in a company

Lessons learned when developing software in a company:

Add value

• Add value. Look to solve problems, not just build stuff. 
• Be Pragmatic.
• Be a professional; ego trips and flame wars have no lasting value, professionalism does

• Learn, there is always a better way.
• while(developing) { Have a personal process and refine it }
• keep a journal/log/todo at all times. keep a running queue or stack (depending on how you organize)

Be a good teammate

• don't try to keep everything in your head, put designs and thoughts in paper to formalize.
• Extremely high rate of return on information sharing. Collaborate.

• Utilize tools so you don't have to make new ones that do the same thing.

Specs

• Implement to spec. If so spec exists, document. The document is now the spec.
• Writing code is part of the solution, after the problem is understood.
• Write to the API before creating it, make it something you would want to use.

Quality

• Time to do it right. If the time doesn't exist now, when will it?

• Are you making good software, or just trying to make some software work? Making a quick patch just pushes the time to do it correctly into the future. Fixing will make the problem go away forever.

• There is always work to do in areas of performance and code clarity/quality. Schedule this as part of the time spent.

Complexity

• Aggressively attack complexity or it will catch up with you.
• Don't be too clever for your own good if clever adds complexity. Be clever in simplifying. Complexity will cause brittle code and crusty developers, avoid needless mental work in code.

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.

Scrum, XP, FDD or Kanban? Use all of them!

There are lots of terms in the agile development world; its clear that we still figuring out the best way to make software. Here I illustrate the use of software development methodologies and what I have seen work in past projects. A lot depends on the project, the people available, and what the end goal is. What my intention is to illustrate that one process or methodology isn't the answer; but instead the most effective process depends on your situation. Its the same as using a screwdriver with nails, or a hammer with screws. Be pragmatic and use the tool that is appropriate for the job at hand. The main goals is the same: create quality technology.

Scrum time

How do we go about doing this? Let's firstly understand how Scrum can be used for organizing how people work together to build both projects and products. Scrum can be used to build anything; a bird house, a home renovation, car repair, and software. It's got nothing to do with the actual technology and everything to do with organizing the group of people doing it.

It can work to realize and understand some fundamentals of how we are doing any of these things:

• where am I in building this?
• what am I trying to accomplish today?
• what are the dependencies that I need to get that done?
• what is preventing me to getting this done?

Scrum the Bad

Scrum can work, but too often its miss-used; and becomes a tracker of time sheets and velocity at the expense of the product the team is actually making. Care about adding value to the product, as no customer is paying the company for time-sheets or velocity. These metrics just don't matter in the end.

Dependencies

For someone managing this process, those last two points are everything. If some piece of work is dependent on other items getting done, the job is to make sure those dependencies are in order and getting done; and if those items are blocked in any way.
In our home reno project; a plumber may be ready to install the bathtub, but to install it the materials need to be there(pipes and a bathtub). So the buying the tub and transporting from the store to the house is a dependency.
For software, its could be a button on the UI that submits a form; you could have your UI developer create that, but if the server API doesn't exist and the logic isn't in place to save the value in the database; then that UI developer is blocked. Ideally these dependencies are in place by the time that front end work starts.

So if Scrum is a general way to organize people, then it needs to be used in conjunction with a methodology that actually builds the technology. These are when terms like XP, FDD, Spiral come in. So, when talking about Scrum, it's really Scrum/XP or Scrum/FDD, or Scrum/RandomConversation. Only with that combination you can have a chance of starting and stopping a project; Scrum helps you organize the participants of a project; but you need a definition of starting and ending. Is Random Conversation a process? Not officially, but many organizations use it!

Product or Project?

Firstly, what is the context of the effort? is it a one-off project for a customer, or a scheduled release that adds to a product? For a one off project you have constraints of time, since you are getting paid based on the time spent and when the project is over there is no more development.
For a product, the constraints are the features in the product. So the measure of success is the amount of value you add to the product, and how it sets you up for the next release. For the sake of analogy; its more like continuously growing a garden that produces vegetables than it is getting one plant growing and produce one vegetable that you give to the person asking for it.

Product

• increased importance of maintainability since you have to live with this code for the long term. You have the opportunity to get it right over time over a number of releases, but you have to deliver enough value so the product can be used today.
• High need for innovation as your effort is trying to add value to a product that your competitors don't have. What is the differentiator in what you are making compared to the competition?

Project

This is something that is budgeted with money, so it's a time and materials type of effort. The client is really just wanting a working tool that solves a single problem; so the need for innovation and invention generally isn't part of this. Its important to use established technology and process so that the project has a measure of predictability. This is essential. If the project ends with the technology unfinished, who is going to pay for the remaining time to complete it?

• you have one chance to get it right, so there is an increased importance in requirements and design, and only building what you have time to do. 

How do to this?

Product

If you are making a product that has no customers, then you are adding features to get to a first version that you can release and get on the road of paying customers. This is where the concepts of MVP and Definition of Done apply. What is the simplest version of the product that fulfills the users goals and solves a real problem? For this, using Scrum/FDD or Scrum/XP has been very effective to constantly iterating to get you to that first release.

What happens after that first release? You need to keep iterating on the product to increase its value for the next release, but you also have customers using it, so you need to respond to them and fix their issues (or not).
For this, split your effort accordingly.

1. Continue to use the Scrum/whatevermethodology you used to get there, and use the same sprint cadence with people dedicated to that process. This work can be planned, you are in control of how much you take on, how much innovation is attempted and what you are happy with to release.
2. Use Kanban to organize the unplanned work. As issues come in, have someone dedicated to managing this so that the customer gets a response, and the learnings from that make it as inputs to the next sprint. It may be best to have someone dedicated to support during each sprint so the other members aren't interrupted; but rotate this position as it becomes a bit of a grind)

DO NOT combined planned and unplanned work in the same process; you will end up doing neither well. 

Project

You are making technology to a specification, and that specification needs to be understood and agreed to by the customer and the builders. Getting this correct will make or break your project; so take time to get this right, and get it done. Using iterations during this phase should involve the customer and builder directly, so it's intensive in a people participation aspect, but vital that the expectations and assumptions aren't left to interpretation at the end.

Depending on the project, a number of methodologies are useful here. Waterfall can work here, and the software may be part of a larger effort, so it's important to use a similar overall methodology for the whole project. This is also about predictability; so invention isn't really welcome here, and using established technology is necessary. This may seem less fun at first, but going over time and having to work for free to fulfill the expectations that were agreed upon at the start is a whole lot less fun.

Wrap it up

For Projects

1. Use established technologies (even if they feel old-school, the client probably isn't paying for innovation) 
2. Invest time in getting the specification correct, and set expectations for further changes. (Jobs to be Done, and Domain modelling)
3. Aggressively remove work if its not needed
4. Identify and resolve dependencies and understand whats needed 

For Products

1. Use Scrum with a methodology to plan and execute feature sprints. (Personas, Jobs to be Done, Quality Model)
2. Use Kanban to organize unplanned work so feature work isn't interrupted and customer requests are addressed.
3. Review each sprint to ensure each release is better than the last.
4. Innovate and add value so that the product is needed by its users. This is a process that lasts as long as your product is successful; so foster a culture of continuous improvement to get better over time.

It can be done! Projects are similar regardless of the technology; the client needs something to spec since the time and money is finite. So if its a home renovation or a website; use established tech and keep expectations realistic. For projects, you need to continuously add value while being responsive. Doing either well isn't easy, but it can be done by sticking to some sound fundamentals.