Waydev - Git analytics (2018) version 1.0

could approach to how dev work could be measured

Looks good! I will sure give it a try :)

Giving non-technical founders insight into the activity/impact of their developers is a hard problem, especially when those developers are contractors.

As a founder, your goal is to have an impact on your customers and the work your developers do should directly affect that impact. That impact is measured by the value added to your customer's lives. How can you measure that?

As someone below said, measuring lines of code for a developer is like measuring words on a page for a writer. There is no direct correlation between lines of code and impact on your customer.

I've seen codebases that have waaaayyyy too many lines of code for the work they perform. These extra lines of code only serve to slow down progress the longer your software is in production. You do want to be in production for a long time don't you?

The other metric, commits, is lacks a direct correlation to the impact on your customer. I am a developer that likes to make a bunch of small commits as I work to confirm that the software is working along the way. Other developers I know like to make one large commit for their work. Neither approach is a good one...just a different one.

Overall, as a technical founder, you need to find developers that you can trust and neither of these metrics is a good measure of that trust.

What are good metrics? Here are a couple that I've used successfully in the past:

Number of stories in process - the more that you have in process means the less you have in front of actual users adding business value. Think of in process code like inventory on the shelves of a grocery store. It costs you money to have that sitting around.

Time from start of work to production - not a great success metric but when this grows you know it is time for a conversation to find out why it is growing. Is it because your stories are too big (again think work in process/inventory). Is it because it takes you too long to get from dev complete to production? These questions can only be answered via conversation, not metrics.

Overall, as an industry, developers owe it to their founders to deliver actual business value as quickly as possible. If you feel like your developers aren't adding that visible, measurable value your customers care about then it is time to have a conversation about that.

Pros:

Nice UI

Cons:

not a good way to measure impact of a developer

This tool seems targeted at small businesses and entrepreneurs. I'm using it to track the work of a remote team that is handling the development of an iOS app.

Pros:

nice UI and simple way to track development

Cons:

for big projects it would need additional metrics

We had been developing an app for fashion industry and the contact with the developers was truly hard. It was a real need for me to have a close look of what is happening in developing. Now I can know how things are going.

Pros:

For me as a non-tech is a great thing.

Cons:

I find it slow and I didn't find easy all the features.

This can easily be manipulated, and provides a false sense of insight into development work.

I hate to review a new startup this way. I just think that measuring these metrics is an ineffective strategy that discourages good behaviour.

Pros:

none

Cons:

Relatively meaningless metrics

Be careful what you measure, you might improve.

You want to focus on the outcome, and not the output.

Pros:

None

Cons:

Not a good way to measure engineering effectiveness

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." - Dijkstra

Great way to incentivize bloated codebases and needlessly granular commit history.

Pros:

None

Cons:

Horribly misleading metrics

You cannot really compare lines of code and closed tasks between developers. I mean, the tasks have different complexities and take different amounts of time and code lines. It would only bring frustration to the team to measure effectiveness in this way.

Pros:

none :)

Cons:

micromanagement at its finest

I will affirm a lot of what was previously said and my words will be inadequate to describe how bad of an idea using this product to measure any development team, remote or otherwise by a non-technical founder. At best it's useless at worst it will be damaging. It's snake oil. This application measures activity and activity is not productivity. The measures reward and incentives the wrong things, which will ultimately not get you what you want but it sure will get you what you ask for. This will show: * Healthy or productive team or team members putting the least amount of thought into their work with the highest bug rate and re-work rate. Exactly the opposite of what you want. At best this will be incompetence, at worst it will be devious. * Unhealthy or unproductive team members who do the following critical tasks that will give you a healthy code base to release, improve, and pivot: * Pair coding, helping, mentoring * Finding and debugging difficult problems * Fixing performance or other critical problems * Doing code reviews * Actual design or architecture that will support a healthy code base and team * Writing tests to verify that the code actually works, can be changed, and refactored. This isn't an opinion, but is based on a ton of research and knowledge the software industry has built over the last 30 years. This application either ignores or is ignorant of this information, and I'm not sure which is worse. You will get good reviews, and people will buy this thinking it works but much like snake oil any positive outcome using this tool as an indicator will be luck or correlation of two unrelated things.