Github developer Scott Chacon describes their development process:

At GitHub we don’t have a project tracker or todo list – we just all work on whatever is most interesting to us. No standup meetings, burndown charts or points to assign. No chickens or pigs. It’s sort of the open source software style of business – everyone itches thier own scratch. Inexplicably, it works really well and keeps everyone engaged, new features appearing quickly and bugs fixed rather fast. No managers, directors, PMs or departments – and it’s the most agile, focused and efficient team I’ve ever worked with. Maybe we should write a book about it.

The first question that occurs to me when reading this is, under what conditions would such an approach work? (The second is, do they have a quality assurance department, and if so, how do they plan their work?)

But let’s go back to the first. I can think of a few prerequisites:

1. Your developers must be users of the product. In fact, I think this sort of approach could only work for companies that build tools for developers.
2. Your developers must be able to iterate without relying too much on other members of the team.
3. The business must not have customers who are promised certain features by a certain date. Customers of every software company I’ve ever worked for have requested features that no developer wants to work on, but they pay the bills, so we worked on them anyway.

There are probably a lot more conditions required to make this sort of arrangement work, but those are the ones that immediately leap out at me. The beautiful thing about this approach is that it insures that you get exactly the developers you’d like to have. The people who would not want to work under these conditions are not the ones you’d want anyway, and the developers you would want would leap at the chance to work in this fashion.

Thanks to Ryan Tomayko for the link.

Update: Be sure to read Ryan’s comment below, he adds a lot more details about how things work at GitHub.

A few days ago I ran into Kent Spillern’s post, Private Methods are a Code Smell. Here’s the meat of it:

Private helper methods indicate classes are doing too many things. Moving private helper methods to different classes, including creating new classes if necessary, splits the original responsibilities across multiple classes leading to simpler, better designs.

This post hit really close to home for me because I’m a heavy user of private utility methods. Splitting code up into lots of methods is a form of self-documentation that I advocate. He talks about one misuse of private methods that I don’t indulge in:

Sometimes, private methods are created to split complex logic or processes into small, easily digested pieces. Often, such private methods have gnarly dependencies because they directly access or modify internal state.

I write private methods for the reasons described in the first sentence, but I very rarely do what’s described in the second sentence — write private methods that modify the member variables in a class. Recently, though, I’ve started moving away from private methods. I don’t mind classes with lots of methods, but when you’re writing tests, it’s easiest to deal with small bits of code with known inputs and outputs.

I’ve also gotten used to frameworks like Rails and Kohana that both support the concept of helpers, which are a sort of thowback to procedural programming. I like helpers because they’re easy to test, and because you can use them in any situation you like. The more object-oriented alternative to writing helper or “util” classes is to use superclasses. Classes that share functionality extend the same superclass that contains the methods with shared functionality. This is the approach that the Spring Framework takes.

Even though I’d thought about moving away from private and protected methods, I had never really thought of them as something to be deliberately avoided, but I’m halfway along the path to being convinced.

O’Reilly Radar’s best and worst tech of the decade inspired me to think about trends in software development. In the past decade, one prevailing trend has been the migration of process in software development from management to individual developers. Traditionally, process has been imposed on the development team, who usually ignore the process or actively resist it. Or in many cases there just isn’t any process at all.

Traditionally, “process” has been associated with project managers. Most processes had to be applied at the team level in order to work. Whether it was old school process like Waterfall or newer, agile processes like Scrum or Extreme Programming, everybody on the team has to participate for the processes to work. These processes are heavy, difficult to implement, and in many cases, completely ineffective.

The most powerful contribution of Extreme Programming, though, was that it was much more developer-friendly than the other approaches, and it really arrived as a bundle of specific practices. XP made it easy for developers to pick the practices that they liked best from the whole collection and start applying them, whether or not management bought into XP as an approach. So we’ve seen specific XP components like test-driven development, refactoring, continuous integration, and small releases really find democratic support among programmers.

A second major factor in encouraging developers to implement their own processes has been the growth of open source software. For one thing, it’s proven to be a laboratory for a lot of different approaches to building software, and for another, all of those approaches were implemented and used by developers themselves, and so they all work for at least some developers. The growth of open source software has also contributed a powerful set of programmer-friendly tools for implementing a development process, including version control, issue tracking, unit testing libraries, automated testing tools, continuous integration servers, project management applications, and more.

The third major change we’ve seen in the past decade or so has been the growth of blogging. People talk a lot about the effect of blogging on other fields, but its effect on software development has been profound. There were ever many magazines that were aimed at working software developers. Back in the day, there were magazines like Information Week, InfoWorld, and PC World that were for IT management — not for the people doing the real work. Developers had Usenet and mailing lists, but blogging led to an explosion in the amount of information that was written by programmers for programmers.

All of these factors contributed to developers stepping up and taking ownership of the process of developing software. These days, you see lone developers implementing a somewhat formal process for building software. Ten years ago, it was tough to find programmers who wrote unit test. Now there are a lot of programmers out there writing unit tests even when people aren’t looking. Programmers are taking ownership of the full life cycle of software development like never before as well. Take a look at some of the more recent writing on continuous deployment — it covers everything from requirements to maintenance to monitoring of running applications. More work done in public, public discussion of that work, and the introduction of new best practices have defined the trend of the decade — developers owning the processes under which they work. Hopefully it will continue in the next decade.

Many Web developers think in MVC, the design pattern that describes Web development frameworks from Struts to Rails to CodeIgniter. What I’m finding lately, though, is that it’s not incredibly intuitive. For one thing, people know what a “view” is (the “v” in MVC), but trying to get people to understand the difference between a “model” and a “controller” can be difficult. Also, what we call controllers in most MVC implementations aren’t really controllers. The controller is a component of the MVC framework itself. Once you’ve built a couple of projects with MVC, that sort of thing doesn’t matter, as long as you get how the applications are built. But these problems present difficulties when training new developers.

The other day I was thinking about another acronym that’s relatively new to me — ETL. It stands for Extract, transform, load and is DBA jargon for the process of migrating data from one data source to another. But I think that for reports in particular, it describes how you should organize your code pretty well.

In a reporting application, extraction would refer to the process of figuring out which data the user wants using the URL and any filter parameters that are passed in, and running the query to retrieve that data. Transformation is the massaging of the data so that it can be presented in whatever format is needed. I strongly prefer having as little transformation code in my reports as possible, it’s usually much better to store the data in the format that will be needed for the reports. And then load, in this case, refers to the process of presenting the transformed data, whether it’s on a Web page or in a downloadable export file.

I think that if you can get developers to think about reports in terms of these three discrete steps, you’re more likely to wind up with code that’s more flexible and better organized that it would be otherwise. You can always yell at people and tell them not to put business logic in the view layer, but creating a mental model that explains why that’s a bad idea might help.