Axioms are self-evident truths. The axioms of Software Development isolate key basics underpinning successful software development. Knowing and using them helps resolve the problems associated with coordinating developers, time and resources, ensuring your software project will be successful and provide a return on your investment.
In part one of this series, I discussed the most important axiom; Axiom 1: Desired features ALWAYS exceed available budget. If you haven’t had a chance to read it, please go and read it first. These axioms build on each other and understanding the first axiom will make understanding the subsequent ones easier.
Here is the next axiom:
2. Communication is King
This seems simple, but it's true and often overlooked. Because features will always exceed available budget, you have to make sure you are communicating enough to overcome that challenge, and thus, the next axiom is “Communication is King”.
Too often I see software projects sending the developer off on their own to build something. The developer comes back two weeks later, and the client says, “Um, that's not what I wanted.” This shows there is a lack of communication between the developer and product owner for that two weeks.
You must keep communication very, very high between the stakeholders of a software application and the developer. That means lots of deployments and demonstrations while the software is being built. Lots of updates in chat rooms or screen shots of designs and progress.
Whatever works in keeping communication as high as possible
Communication is the most important thing that will derail a project. (Outside of the client expecting all the features for no money.)
If communication drops out, the client starts to feel ignored. They don't have any reality of what's going on anymore and because they don't have any reality of what's going on, their love of the project will start to drop. In a month or two the whole thing blows up in your face.
We have rules in reinteractive where our developers need to be updating the client two or three times each day on what they are doing and where they are going with the project. This usually is done as follows:
- A morning text update as the developer is starting work “I plan to work on points A and B today”.
- A stand up call with the client (preferably with the video on) to go over any issues or blockers or to clarify things with screen sharing.
- A mid-day update “A is done, I’m now working on B”.
- An end of day update “OK, B is taking longer than expected will continue tomorrow and will get onto C as well. I’m heading off in 15 minutes if you need to ask me anything”.
That level of communication keeps our client engaged and up to date. Some of you might think, “why bother with a morning update if it’s basically the same as the evening?” Well, it turns out that quite often, that overnight, after the developer has stepped away from the task and woken refreshed the next morning, a new way to tackle said problem has materialised. Also, the morning update reassures the client that we are working and active.
We put all of the work we are doing into stories in our task tracking system so that the client sees what's happening. Clients are constantly reviewing and accepting the various stories through the various changes.
Working out Key Performance Indicators
After finding this axiom on communication, it helped me resolve another problem I had, which was trying to work out the key performance indicator (or statistic) of a developer. I had spent quite some time trying to work this out.
When you go out to the market and ask people what the KPI of a software developer is, you get back answers like ‘hours of coding delivered’ or ‘lines of code’, or something of that nature. None of that really worked for me. Because if it's lines of code, the way you achieve a better KPI is to just hit return on your keyboard more often and make the lines shorter. "Hours spent coding", well that's obviously not the right thing either because one way to increase such a KPI is to get worse at coding so it takes you longer. So, neither was right.
The KPI I settled on is “features delivered and accepted as done”, with no regard to how big or small the feature is. It's just the number of times a software developer delivers an item of work that is then accepted as done by the client of that project.
This creates a very interesting game dynamic between the client and the developer. The developer will want that KPI to go up as high as possible.
When creating a sign-up form, it will be broken into 10 different stories, 10 sub-features. That's totally fine. Because that forces the developer and the client to have a higher rate of communication. The client now has 10 features to review and accept on the various aspects of that form and it gives the client more opportunity to say, “Oh - we forgot number nine”. As opposed to 'Oh, yeah, the sign-up form kind of looks like it works so I'll hit accept”.
So, it actually increases the communication level between the client and the developer, which is something we very much want, and the client is saying “Yes this is good”, many, many more times during the development process.
The KPI of our developers: “number of features delivered and accepted as done by the customer of the project without regard to the size of the feature”.
What I mean by “without regard to size” is you might have something like, ”implement the dashboard”. The developer might say, “Well, that's a feature worth 20 points”.
Don't do that. Don’t assign a different value to different features. Just make every feature worth one point on their KPI. And if you do it that way, the developer will drive the size of the feature down, because they want more points. And that will drive the communication level up with the client who must review and accept each one. It is a great way to keep that communication high.
And keeping communication high is something your clients love. The feedback we receive says they feel they are always in control and know what is going on with their software build.
Why Rails Upgrades as a Service?
The Axioms of Software Development - Part 2
Type less when using Git on the command line with gitsh
reinteractive is Australia’s largest dedicated Ruby on Rails development company. We don’t cut corners and we know what we are doing.
We are an organisation made up of amazing individuals and we take pride in our team. We are 100% remote work enabling us to choose the best talent no matter which part of the country they live in. reinteractive is dedicated to making it a great place for any developer to work.
Webinars are our online portal for tips, tricks and lessons learned in everything we do. Make the most of this free resource to help you become a better developer.
The Ruby on Rails Installfest includes a full setup of your development environment and step-by-step instructions on how to build your first app hosted on Heroku. Over 1,800 attendees to date and counting.
The Ruby on Rails Development Hub is a monthly event where you will get the chance to spend time with our team and others in the community to improve and hone your Ruby on Rails skills.