You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Feature Branches with Code Reviews

February 26, 2013 — JaZahn

We have been trying to find a process for doing code reviews for a little while. Because most of our current projects are in github, it made sense to try and use some of the github features to help in this process.

I have been using issues for stories and milestones for sprints for a while. And it works out nicely because I get a pretty neat gamificationy results.

So I started using a feature branch in order to have the ability to make pull requests on my own project and get a discussion thread before code is merged into the trunk (production).

https://github.com/Harvard-ATG/Quizmo/pull/119

This discussion is a great way to get a reasonable code review before merging code. Right now we’ve decided to only do this for non-trivial changes, but with a very high bar on “trivial”.

Posted in ATG, Development. Tags: , , , , . Comments Off on Feature Branches with Code Reviews »

Forcing Client Involvement Through Production Releases

February 22, 2013 — JaZahn

What I take away from agile is the idea of putting something in front of a client as quickly and as often as possible. Of course things are going to have flaws, and things may be unfinished, but having the client see what you’re doing gets a sort of course correction done that doesn’t happen in a vaccuum. People tend to understand this, but they don’t often abide by it.

The problems I’ve seen lately have been in the instance when there is no client directly involved in the process. In that case, a product manager is assigned to take on the role of client, someone who mostly understands what the client wants and basically be their advocate. But the product manager, being an employee and not a client, doesn’t want to risk releasing an incomplete project for fear of how that will look or how the client will react to that. Therefore purposely not involving the client in the only part of the process where the client could give direct feedback — in production.

As long as it’s explained to the client that they are dealing with an alpha, and we welcome feedback on things they feel are necessary, it seems they could be used at that part of the cycle to offer feedback and keep features that will never be used from being added to the project and keep the project from straying too far from something they don’t want.

Posted in Agile, ATG, Development, Quizmo. Tags: , , , , , . Comments Off on Forcing Client Involvement Through Production Releases »

Agile Context Switching

January 31, 2013 — JaZahn

I had the pleasure of trying to work on 3 separate agile projects last sprint. I typically get 40-50 story points done in a sprint. I like to take on more than I think I can do to keep myself from letting work expand to fill time. I also had the issue of having to take on another developer’s work. Total, we promised ~80 story points.

Now, when my kid was new and I wasn’t allowed to sleep nights, I was able to cram 70-80 sps into a sprint. But sleep has made that level of productivity very hard.

I was also tasked with working offsite, organizing a community of practice, and trying to learn a very large project through “osmosis”. Which is to say, learn as much as you can without reporting time spent on it.

I have to admit, all of the work is interesting and the clients are all people I personally don’t want to let down. So it’s hard to say “forget project X”. (Which is hard to say generally when there actually is a project X.)

So with many things pulling me in many directions, my completed story points for the sprint was 33. A significant decrease in general productivity.

Context switching needs to be allocated for in sprint planning. Duh?

The trick is how much? Some people say it takes 15-30 min to effectively context switch. That’s part of it. I think the larger part is when you’re focused on one-two items, you can finish things effectively. The more items, the more you end up with partial work. Partial work is the worst time killer. You get 50% into a feature and if you have to stop and start again it magically turns into 30-40% done.

Solution? Don’t switch contexts.

Har har. Work on something to completion before switching contexts. Be strict about it.

Posted in Agile, ATG, Development, Flashcards, Harmony Lab, Quizmo. Tags: , . Comments Off on Agile Context Switching »

Back in Time with PHP

December 16, 2012 — JaZahn

I recently had the opportunity to work on a PHP application that was written by a student in 2004. Before the time of PHP frameworks and separation of MVC, when applications had SQL and HTML in the same files. Each page was a form that submitted to itself. Everything contained in one file per page. Pretty crazy, right?

Crazy like awesome. I had so much fun working on features for this old application. It wasn’t just nostalgic, it was like comfort food. Easy and delicious. I’m not really sure how comfort food is “easy”, but just go with it. I was practically begging to do more work on it.

I can’t imagine myself creating a new application like this from scratch, but I’ve been thinking about the benefits. Anyone with just a tiny bit of PHP experience could pick it up and maintain it, there’s no technology ramp-up time. A project like this could be orphaned and passed around between anyone. It could be used to teach people basic PHP within the organization. Say, people who are so Java-centric they refuse to learn anything new or different.

It was a good opportunity to take a look at the past and see what we’ve lost by going forward with technology.

Posted in Design & Modeling, Development, PHP. Tags: , . Comments Off on Back in Time with PHP »

Deciding on a Style Guide

December 15, 2012 — JaZahn

Recently a couple of groups here at work were brought together to try and standardize on a few things. The Software Development Community of Practice! Style guides came up. Everyone said they had no style guide and everyone agreed having a style guide would be worthwhile.

I had spent some time writing a style guide (customizing) so I was interested by this. I got to reflect on my style guide, how I’ve referred back to it in the year since I put it out there, and how I think it has helped or could help in this forum.

See the reason I created this style guide is not all that different from the reason these communities of practice are looking to create style guides. I was/am writing open source, and on the hope that someone will want to contribute to the project, I want a rule set defined so people won’t submit something unreadable.

For the community of practice, it’s a little different, but the spirit is the same. What they want is to have the option to point at something when a fellow developer is writing horrible code. The premise is you have a new developer and they don’t know how to write clean code.

The problem I have with this is everyone knows how to write clean code. And by everyone, I mean every professional software developer. If they’re not writing clean code, they’re not professional. Now that of course means if we are using student employees or taking in work from unknown outsiders (Open Source), that we are risking poorly written code being introduced and should therefore have a style guide. But if the premise is to have something for professional developers, I think it’s a waste of time.

Most style guides are 95% the same and we’re not talking about trying to enforce the 5% that is going to be different between individual developers. If ever a problem comes up with software developers where one is trying to say another’s code style is wrong, they should be able to say “google a style guide to see what best practices are” and be done with it.

Sadly, I’ve wasted more time arguing this than it would have taken to just agree, pick a guide that no one will ever use and move on.

Posted in Development, Open Source. Tags: , , . Comments Off on Deciding on a Style Guide »

The Code Monkey – Devaluing Software Developers

November 20, 2012 — JaZahn

Code Monkey

Note: Opinion. This is something I’ve noticed/perceived in all positions I’ve held.

Of course no one is paid enough money. Boo hoo, we all want more money. Although that is a nicely objective way to value employees, that’s not what this is about.

This is about how software developers are perceived by (most) management. If a manager has a software developer and a project manager under them and they get conflicting reports/opinions from the two people, they will always go with the project manager. Management typically looks at a developer as an overly technical person, unable to understand client and business needs. So when a developer goes for a management position, they are shot down because they are “too technical”. (When someone gets turned down for a position in an IT organization because they are too technical, something is clearly wrong.) The perception of management is clear. PMs get the attention and typically the praise. PM ideas are seen as coming from a position that’s higher level because a developer works in the nitty gritty and doesn’t think in terms of high level.

A software developer ideally understands the client and business needs just as well as the PM. Given that’s an ideal, but that’s what makes a good developer good. Often the reason a project turns out bad is the developer wasn’t made aware of why they’re doing what they’re doing. (Sometimes that’s because it hasn’t been thought about on a high level — no one really knows why.)

The truth of it is software developers come in good and bad the same as project managers. Some are really good and some are totally not. The problem is most management don’t bother to get to know their employees, so they don’t know who is good and who is bad so they make generalizations based on role. That’s bad.

Of course you can now say I’m making a generalization about management in the same way. And you’re right.

Posted in Development. Comments Off on The Code Monkey – Devaluing Software Developers »

Gamification in Software Development

November 10, 2012 — JaZahn


Gamification has been on my mind a lot lately.

I was just doing some of my sprint planning and found myself filling out borderline excessive github issues for my project. I put all of the issues for the current sprint into aptly named milestones. So as I finish the issues in the milestone, the milestone progress bar gets filled up. I recently realized I enjoy doing this because it’s very game-like.

I’ve turned work into a game and I think it has increased productivity and general happiness with employment. Maybe that sounds lame, but it seems true in my case, I would recommend it for most people who are finding their current work stale and are looking for some self motivation.

Posted in ATG, Development, Gamification. Tags: , , , , , . Comments Off on Gamification in Software Development »

Agile Documentation and Research Stories

November 2, 2012 — JaZahn

A few months into our switch to a more agile process, it became apparent that we still weren’t able to find a place for documentation in our sprints.

At first we had the idea that we would add a task to each story that would cover documentation. We found that we would end up writing docblocks and general code documentation but actual user documentation never got written. But we did that before so we really weren’t getting done what we were trying to get done.

Our next attempt was to set aside a day at the end of the sprint where we would write documentation or finish up stories that were not done yet. But I’m not sure how other people are doing point allocation in sprint planning but I think the ideal is to try to go just a little over the to of what you’re capable of. That keeps you working hard. At least for me, if I know I can do 50 points in a sprint and I schedule 40, I will get 40 done. Work expands to fill time. My point is there is always work to get done on the last day of a sprint. Scheduling documentation within the sprint separate from story points just doesn’t work.

That brings us to documentation stories.
As a developer
I need to document this functionality
So I can easily refer back when there is a problem in the future

This would be great, if during sprint planning, these stories actually got priority. The client wants a cool app, they don’t care about user documentation when you could instead be giving them a bell or a whistle.

What we have had are research stories. These are stories where we investigate options. i.e.
As a developer
I want to figure out if X is doable
So I know if this technology is the right way to go

These stories come up often in our process. We typically have been simply making some notes and reporting back at the retrospective / next planning. This was fine for our purposes but then we realized we could be creating a slightly more professional looking set of notes and pass them off as user documentation.

This doesn’t cover every aspect of user documentation, but it can get a lot of useful documentation done. How did we do our ldap data? We have documentation of our options and our final choice and why.

Currently we have been writing all of these in google docs so they can be easily collaborated on. We then paste them into the project wiki. It appears to be working.

Posted in Agile, ATG, Design & Modeling, Development, Uncategorized. Tags: , . Comments Off on Agile Documentation and Research Stories »

A little bit of Agile, a dash of Open Source, and a pinch of ITIL

October 30, 2012 — Michael D. Hilborn
Agile, Open Source, and ITIL

From left to right: Agile, ITIL, and Open Source: An (un)holy trinity?

So I’ve hopefully started what will become a multi-part series about integrating Agile, Open Source, and ITIL into an overall strategy for delivering web services. You can find the first part on my personal web site. WARNING:  The first post is simply a high, very high, overview of the three methodologies, so you may find nothing new in there.  Indeed, here’s a snippet speaking to that very fact:

First, an admission: Open Source, Agile, and ITIL are nothing new to the realm of IT; all have been around for years, if not decades, and many industries have embraced them in some form or another. So the fact we are now incorporating these practices into our work might not seem exactly novel and, if I was strictly speaking about incorporating just the individual practices into our work, such an assertion would be correct. But I’m talking about merging all three, and a quick Google Search on “implementing,” “incorporating,” “combining” or “merging” this trinity doesn’t exactly return a cornucopia of results. So maybe what were doing is somewhat novel, after all.

Posted in Agile, Development, ITIL, Open Source. Tags: , , , . Comments Off on A little bit of Agile, a dash of Open Source, and a pinch of ITIL »
«
Newer posts » »