You searched for articles tagged with Agile.

Question Permalink

Git, Agile Added less than a year ago

Why are SCM and ticket systems separate?

e.g. Why use git or svn and then have to tie them in with RT or Jira? Couldn't there be a nice command line utility that reports on tickets and bugs too?

Instead of tying commits to bugs in external reporting systems, it would be great to issue some command in your SCM to:

... etc.




Gauging Developer Progress Permalink

Rant, Agile Added less than a year ago

Here's a ridiculous article that attempts to espouse the benefits of counting lines of code (LOC) by comparing software development to house building: Counting lines of code can help measure progress

Development is often compared to building a house. I’ve built a house, and I can tell you that while I did want the bricklayers to be finished on time, that wasn't enough to satisfy me when I had to write the check. Generally, I’d check their progress every day, and I would notice how much brick had been laid.

What this moron and his ilk fail to understand is that software engineering is a different style of work to ... well, anything. Let's take his building example. A house, 99% of the time, is a solved problem. A builder who has worked on previous houses already knows exactly how to build the next house (unless it's a fancy architectural-type house, or it's built on sand or made entirely from glass etc.) In software development however, if a large problem has already been solved before then that module (or open source library) can be reused. Therefore new work being done by devs often (not always) fits into one of these categories:

... and this work can be equally or more important than new features written from scratch. It can also be less important - it all depends on the value of the features, not on the lines of code it takes to write them.

Both refactoring and bug-fixing can sometimes actually reduce the number of LOC in an application, because existing code is studied for any inefficiencies or errors and newer, simpler, more modular, more elegant code replaces it. If you were measuring LOC based on changed lines then this would be taken into account, but if you are measuring LOC based on new lines then this work would be ignored. Let's say we were indeed taking into account changed lines, and we have an example where 5 lines were altered and 3 lines removed to give an efficiency increase of 300%. Should these 8 line-changes be given equal weight to 100 lines of code elsewhere that only adds one small feature? You would have to compare the value of the small feature to the value of the efficiency increase!

Compare ticket values, not lines of code written.

Sometimes a bug can be so insidious that it can take a whole day to find and fix - and it might be a one-line fix. Should a developer be punished for this, just because his daily LOC measurement is low? What if the bug-fix was a show-stopper? Even our old friend William Gates thinks that would be a bad idea:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

Scrum takes care of the problem by examining relative complexity values during sprint planning meetings. Once a list of tickets (items to be worked on) have complexity values you can estimate their development time and equally distribute the tickets among developers. Progress assessment is now easy, managers just need to check the burn-down charts... and that eliminates the need for misguided and archaic measurement techniques like LOC checks.




Colophon

Django, Python, 960.gs, Git, Vim, WebFaction

The Author

The author is a software engineer living in Australia. He sux at guitar, loves camping, doesn't like cake, does like coffee and is a lazy home brewer.

Meta

Help
Latest entries

Agile Apple Athletics Beer Censorship Comedy Cool Django Git Hardcore Javascript Languages Perl Python Rant SQLite Shell Slackware Standards Subversion Testing Vim WDTEM

Frequently Used Redirects

/r/365/
/r/hoadster/
/r/debono/
/r/dd/
/r/uncleian/

♥ Actors/Artists/Characters