software development – Page 9

Tag: software development (page 9 of 16)

Commit access on work projects

Jacob Kaplan-Moss on who you let commit code to your projects:

What’d you do the day you started your job? Got a little tour. Found your desk. Some HR paperwork. Figured out the network. Set up your new company machine. Got your VPN credentials.

And got your commit access to the company’s source control.

Normal first day procedure, I know. And yet, that day-one-commit-bit is one of the starkest differences between the corporate and the open source development model.

I can think of good reasons for the difference, but I’m going to think about this one for awhile.

Making a full commitment

November 8, 2009 / Rafe / 3 Comments

I ran across a guest post at Smart Football this morning when I was trawling around looking for more takes on UH’s ridiculous last second 46-45 win over Tulsa last night that I think applies to just about any field as well as it applies to football coaching. The piece is a provocative argument about how to implement offensive schemes in football, but it could just as easily apply to adopting agile development practices on a software development team. Here’s the part that really resonated with me:

Before discussing the technical benefits, let me first say that operating exclusively out of a four-wide environment is the first step a coach makes towards acculturating his program to the offense. To run the run and shoot effectively, it is necessary to commit to it entirely. Coaches that retain the ability to use tight ends, h-backs, and multiple-back sets create a crutch upon which they can fall back on when things don’t go as well as they’d like in the early going. Inevitably, what happens then is that the team becomes a multiple-set team that uses some run and shoot packages on passing downs. What never happens, however, is that the team converts to the run and shoot culture. And without that, the coaches and the players never become fully comfortable in the system, and then when the team struggles more, they blame the system.

When you decide to run this offense you need to burn your bridges with the past. You have to declare, “This is what we will sink or swim with. We are a run and shoot team.”

There’s a lot of wisdom in those two paragraphs, in that they describe the difference between a plan on paper and what happens when actual humans try to implement a plan. As a coach (or software development manager), the temptation is always to try to keep your options open so that you can adapt to any situation that arises, but what often happens in those cases is that it can leave the team confused. The more branches you have in your logic, the easier it is for team members to make poor decisions and to second guess the decisions other people are making.

Let’s take test-driven development for example. I don’t believe it can work without a full commitment. Either you demand that tests are written in all cases, in the manner prescribed, or you can watch your TDD regime wither away as competing pressures give people a reason not to write tests. In some cases, applying TDD may not make the most sense, but using it anyway creates a culture that practices TDD. This doesn’t answer the question of whether TDD is the right or wrong practice for a particular team, but once the decision has been made that it is, only a full commitment will lead to its successful application.

You can apply this logic to any practice a team wishes to adopt, whether it’s as small as always writing a descriptive comment when checking in code or as big as using pair programming.

Just as team members must have the discipline to implement the philosophy that the team leader prescribes, so too must the team leader have the discipline to choose a philosophy and make a full commitment to it. Or at least that’s the argument that the poster makes.

Could we have “stages” for programmers?

November 2, 2009 / Rafe / 9 Comments

There is a very interesting practice in the restaurant industry, where chefs do unpaid work at a restaurant in hopes of learning (and perhaps in hopes of getting a job there). The term for these placements is stage — pronounced as the French would — “stahge”. Here’s one chef’s account of a stage he’s doing. You can learn a lot more about how a stage works in this three part series by Dean McCord.

It seems stages come in two forms — part time work over a long period of time or a short, full-time unpaid stint in a kitchen. Ultimately the fact that these programs work is a testament to how chefs see each other. Clearly chefs put a very low premium on secrecy — they’re not worried about competitors finding out about next week’s specials. And I think it also depends on the fact that chef skills translate well from one kitchen to another. A chef who has mastered the fundamentals can begin contributing in a new kitchen relatively quickly.

What I’m wondering is whether this kind of approach could work in software development at all. Would you be willing to take on a part time programmer who wanted to learn from how your company develops software? If you were between jobs, would you spend a week or a month working on someone else’s project free of charge in order to learn and potentially get a job? Would you take a week of vacation to work with developers you really admire? Would your boss let you? And finally, do you think you could offer a developer who came in cold to work on your project for a week meaningful work that left them feeling like they gained something from the experience?

Preparing for continuous deployment

September 29, 2009 / Rafe / 3 Comments

Since I watched the Tim Fitz video that I linked earlier, I’ve been thinking about continuous deployment. Whether you are really going to deploy every day or not, the idea that your code base is always in a position where it could be deployed immediately is enticing. As Tim points out, getting your code into that shape means that you’re getting a lot of things correct.

So I thought I’d break it down a bit and look at the steps required to get an application in shape for continuous deployment. From the presentation, it seems like the major steps are as follows:

Get your house in order with regard to deployment. If you’re going to be deploying frequently, you need a fully automated deployment system that works quickly and effectively across your whole cluster. The complexity goes up if you’re pushing database schema changes that would ordinarily require downtime. You also need the ability to easy roll back your deployments in case things go wrong.
Set up a robust suite of automated tests. To set up continuous deployment with confidence, you need to feel pretty comfortable that bugs won’t make it past your test suite. If you don’t have tests, this is a big hurdle to overcome.
Set up a continuous integration system. Once your tests are set up, you need to automate them so that they’re run every time code is committed. If necessary, you have to set up this system in parallel so that tests run quickly enough not to gum things up. (In the presentation, Fitz mentions that their full test suite takes 6 CPU hours to run and is split among 40 machines).
Build a monitoring system that is effective in catching post-deployment problems. When you’re deploying all the time and relying almost solely on automated testing to verify your builds, you want to monitor your application to make absolutely sure that everything is in order while it runs. This is your last and best line of defense against errors that are causing problems in production but that you haven’t noticed yourself.

While all of those things are necessary to implement a continuous deployment system effectively, it seems like these are all features you’d want for any application. I’m going to explore getting the application I work on into a state where it could move to a continuous deployment and write up what it takes to get all of the prerequisites set up.

The big question is whether it’s possible to invest the effort to put the work into setting things up so that continuous deployment could work if you aren’t actually going to do it. The truth is that while all of these features are really nice, there are a lot of applications out there that get by without them. Even so, I’d love to give it a shot.

Tim Fitz on continuous deployment

September 29, 2009 / Rafe / 0 Comments

I’ve discussed continuous deployment before. The idea is simple — ship more often — ideally, with every single commit. The last post was about blog post explaining continuous deployment by Eric Ries, CTO of IMVU. For more on the concept see this presentation by his colleague, Tim Fitz, on the same subject. I am very much intrigued by this concept, if only because it frustrates me when release cycles slow down so much as applications mature.

Links for August 31

August 31, 2009 / Rafe / 2 Comments

MySQL Performance Blog: Give me 8 hours, and I’ll help you build a better application. Three simple things you should to to make your applications more robust.
Andrew Sullivan: The Rotten Core. As Alasdair Gray said, “Work as if you live in the early days of a better nation.”
Foreign Policy: Think Again: Africa’s Crisis. Things aren’t as bad in Africa as you think. This is a short article that sheds lights on a lot of popular misconceptions.
Amateur Gourmet: Dinner at El Bulli. The closest I’ll ever come to eating there, except perhaps when I watched Decoding Ferran Adria.
Business Week: Where Have You Gone, Bell Labs?. An argument that job creation has stalled due to a lack of basic research.
Financial Times: The Iraqi who saved Norway from oil. Absolutely brilliant feature on an Iraqi petroleum geologist who emigrated to Norway in 1968 to get proper health care for his daughter and walked into the opportunity of a lifetime.

Why do Ruby developers test?

August 14, 2009 / Rafe / 4 Comments

Giant Robots asks the question, Why Do Rubyists Test So Completely? It’s a good question. Developers on other platforms would benefit greatly from the culture of testing that has been established among Rubyists (and especially Rails developers). They have their own list, and I agree with all of the items on it. I have one reason that I’m surprised they didn’t list.

Rails makes it really easy to start testing. When you generate a new Rails application, it gives you a place to put your tests. When you generate controllers and models, it creates skeletal tests for them. Nobody has to sit and wonder, “What should I be testing.” The framework tells you. So the next step is just to fill in the blanks. Then when you want to run your tests, you just type “rake” in your application directory.

Java has JUnit and all of the IDEs have test runners, but beyond that, you’re on your own. What do you test? How do you organize your tests into suites? How do you run the suites? These are all questions you have to answer before you build a testing regime. Individual unit tests are easy to write, but getting it together to really make a habit of testing is a lot more work than it is with Rails.

And in the PHP world, things are even worse. I have never seen a PHP application with a robust unit test suite, although I’m sure they exist.

The Rails approach makes the biggest difference with people who aren’t already committed to unit testing. If you know the value of testing, you’ll jump through the hoops to set up tests, even if it’s a pain. If you’re not yet convinced, then the extra work required to set up unit testing with other platforms prevents people from getting started. It’s very much the deliberate choices the creators of Rails made to encourage and facilitate testing that explain in large part why testing is such a part of the culture.

Celebrity HDD

August 10, 2009 / Rafe / 6 Comments

I just happened to notice that David Heinemeier Hansson, the creator of Ruby on Rails, learned Ruby through hate driven development. Here’s his answer when asked how he learned Ruby:

I learned Ruby by programming in anger. Attempting to make something real. Not just a toy program.

Ruby vs Python, the final word

August 4, 2009 / Rafe / 0 Comments

The Rudimentary Art of Programming & Development, a programming blog, has done a detailed comparison of Ruby and Python and declared them interchangeable. In my far less systematic comparison, that’s how it has seemed to me as well. Glad that’s settled.

Kirrily Robert on women in open source

July 29, 2009 / Rafe / 3 Comments

Go read Kirrily Robert’s OSCON presentation on women in open source. What I find interesting beyond the basic gender issues is a cultural problem often found in software development communities — a general lack of hospitality for newbies. As the article points out, when we shut people out (either unintentionally or intentionally), what we’re really doing is limiting the scope of what we can achieve.

And we should expect to have to go to extraordinarily lengths to fix this problem, because lack of diversity is a self-reinforcing problem. Non-diverse communities generally become more and more out of touch with the things they need to do if their goal is to achieve diversity. All sorts of habits that are invisible to members but incredibly off-putting to the people who are excluded creep in. Breaking that pattern is tough, but worth it.

rc3.org

Strong opinions, weakly held