Feeds:
Posts
Comments

Archive for the ‘Development Methods’ Category

1. Denial – “Surely that’s not how their API works!”
2. Anger – “WTF are they thinking? Why would anyone do that?”
3. Bargaining – “Hey, would you be willing to change your API? I can make a pull request…”
4. Depression – “This API sucks. I don’t want to work on it anymore.”
5. Acceptance – “I guess there’s no other choice. Is soap4r still active?”

Read Full Post »

Auren Hoffman has a good post on TechCrunch about how now might be a great time to cherry-pick the best software engineers available, and how it can pay off not only in the short term, but also over the long, to hire high-quality developers and spend money on developing them individually rather than hiring more, lower-quality developers. I find that a lot of companies do too much of the latter — but often the cost of hiring more and cheaper is so obscured by differing workloads and hard-to-quantify ‘quality of output’ that it may never be evident. In some cases, though, it can be quite evident — as in the study cited here in Joel Spolsky’s post describing the time taken by students to accomplish the same assignment… and their scores. I’ll steal just one graphic from him:

This graphic shows that some students finished in 12 hours what others took 50 hours to do — with roughly equivalent quality!

I’ve seen this personally, as well — we probably all have — where you know one developer can do something twice as fast as another… so why aren’t more companies hiring based on that? If you have to pay 1.25x as much for a developer who works 1.5x faster… wouldn’t you take that deal? I wish more companies would.

Read Full Post »

InfoQ has a great video interview with Randy Shoup, in charge of search at Ebay, where he talks about several things, including their heavy use of partitioning, the unique issues you run into with such a high volume site, and what’s coming up for them.

Btw, I love InfoQ’s interface for presenting not only the video of the interview, but the transcribed and video-linked text of the interview as well. Great for skipping ahead or when the audio quality drops out and you can’t make out a word.

Read Full Post »

There have been a couple of notable lists written past year about how to get and keep talented developers — first Joel Spolsky wrote A Field Guide to Developers, and then Rob wrote Nine Things Developers Want More Than Money. They both agreed on Rob’s titular point… money is one of the last considerations that most highly skilled developers want. They want to know they’re being paid fairly, but as long as their pay isn’t too far off of what Salary.com says it should be (or they’re getting a stake in the company), then they’re fine from the money aspect. Those two posts go into a lot of detail about how to build an environment to attract great developers and are well worth reading, but I think they both left something out that I’ve seen be lacking for many of my developer friends: managers interested in helping employees develop their own careers.

First, a couple of examples. A friend of mine was doing DBA stuff for a reservations company, and had been for four years. He was generally happy with the job (and had gotten excellent reviews, was liked and respected internally), but was getting restless — four years of Foxpro will wear on anybody. So, he started a conversation with his manager and told him that he felt that he had done as much as he could in his current job, and wanted to talk about other areas that he could grow into — picking up a new language, starting towards a managerial path, etc. His boss was shocked, and told him that he needed him right where he was, and not to worry about “things like that”. The manager followed that up with what has become one of my favorite examples of managerial indifference:

“Just because we haven’t given you a promotion in four years, doesn’t mean we won’t ever promote you.”

That conversation ended with the employee giving notice.

Another friend of mine was working for one of the big telecom companies, and at his annual review noticed that his manager had once again written “Grow in current position” on his review. He asked the manager, “Here are the things that interest me. Where do you see me going from here? What do you think my next position could be in a year?” The response? “Well, I’ll retire eventually — maybe after I leave, you can have my job.” My friend didn’t quit right away, but that was the point when he started drifting away from the company.

So what should you do? Those two lists are a great start, especially making sure developers have interesting work — bored developers leave. More importantly, though, every developer you manage should feel like one of your goals is to help him achieve his goals. First and foremost, that means that you should know what your developers want in the first place. Managers, here’s a quick test: Think of each person you manage. Now, for each person, create a ‘dream job’ for them — no matter how improbable, just focus on thinking of a position or project that each of them would kill to have. For the ones you could think up a job for… it’s good that you know what they want. Hopefully you’re already working with them and trying to get them moving in the right direction, whether that’s through training, additional responsibilities, coaching, whatever.
The people you couldn’t think of a dream job for… well, that’s probably because you never asked what they wanted. By failing to ask, you’ve communicated to them that you don’t care about their personal improvement. You may be giving them kudos and bonuses, but that’s just a reward for the work they’re doing right now. When they lean back and think about where they want to be in a couple years… well, there’s a phrase that’s pretty common amongst employers: “Up or Out.” That’s every bit as true for the employee. When they think about how they want to develop their career, there’s two main choices: improve within the company or find a new job. If your manager has been indifferent, or even worse, negative about helping you pursue your goals, then you probably won’t even bother trying within the company — and the new job will likely pay better anyway.

On the other hand, if your manager is working with you, is interested in knowing how you want to improve, and is not just paying it lip service but is actually taking steps to help you get there… then you’d be crazy to leave. I’ve had managers who didn’t really care before, and while they were good managers, I never felt the loyalty, the devotion to them the way I did to the managers that would invite me in every few months to talk for an hour or two about where I was, what I wanted, and how to make that happen. Those are the managers that developers kill to work for. Be one of those managers.

Read Full Post »

Suzanne Williams at Venture Law Lines writes “If you want to sell your own proprietary software, make sure you have a strictly enforced policy against using open source.”

If only all my competitors would follow this advice. This advice at first sounded crazy to me, but after reading further I think I understand where she’s coming from, even if I strongly disagree with her advice. She says that use of open-source will cause investors to raise four issues:

  1. there is no meaningful warranty or indemnity for this portion of the product
  2. how do we know the open source license is enforceable?
  3. do the terms for this piece of open source contaminate the rest of your product?
  4. if this was inadvertently incorporated into the product, what else was?

I agree that these can be important questions (especially 3), but I think what startups should really do is follow the advice buried deeper within her post: “A strongly articulated policy for use of third party software in your business needs to be developed, posted and enforced”. That’s something that a startup needs to do whether or not they use open-source software. Part of that policy should be a process to track all of the third-party software incorporated in your application(s), and should include at a minimum the library name, source (such as site downloaded from or that it came from a CD), license, and any files or directory paths where the third-party software is stored. This allows for an audit to be conducted where any suspect libraries can be looked up and either verified as authorized or removed if necessary. Should any VCs express concern about your use of open-source software, you have a document that you can give them that clearly lays out what you’re using, where you’re using it, and the license governing your usage.
As for her points:

  1. Generally true, although for many products (JBoss, Red Hat Linux, MySQL, etc.) support can be purchased even though the software is free.
  2. Although most open-source licenses are untested, who is going to be enforcing it? Generally, companies only run into licensing trouble when they take advantage of open-source software by not following the terms of the licenses, such as the recent court case in Germany where D-Link was found to have violated the GPL by including GPL-licensed code into their software and not making it available. Alternatively, if you’re worried about cases such as SCO’s assault on Linux (really more like a back-alley mugging), then you have a lot more faith in SCO’s unsubstantiated case than I do.
  3. This is an excellent reason why you should define a policy for third-party software: after reviewing just one or two open-source licenses (such as the LGPL license), you can put them on a list of approved licenses and your product team has access to a wide variety of third-party software, all under that exact same license.
  4. She points out that often subcontractors cause problems by not going through the software approval process. This is true, but just one of the many ways in which subcontractors must be managed — license guidelines, coding styles, and architectural plans are examples of several things that contractors should be instructed in (and compliance verified in).

The main point leading to her recommended prohibition of open-source software is that it may prevent investors from investing in your company: “…why get to the point where you are defending your approach?” I think the reason most companies, and especially startups, use open-source software is because it is many times more flexible or more agile than most packaged software. There are lower barriers to obtaining software, and if you have any trouble integrating the tool you can actually read the code to see what it’s doing, and fix or enhance it if you need to. (And yes, total cost of ownership over the long run is going to depend less on the initial purchase price but if your choices for a startup are MySQL versus Oracle, it’s a lot easier to get the CFO to front the money for 5 MySQL licenses than for 5 Oracle licenses — especially in the early stages).

Something else to think about if you’re going to forbid the use of open source… what do we lose?

  • Linux
  • Apache (the Internet’s most popular web server)
  • MySQL and PostgreSQL
  • JBoss
  • MONO (run .NET code on non-MS platforms)
  • Perl
  • Eclipse
  • Ruby
  • …any number of other tools, some of which are the best-of-breed

…and even Java, which recently announced that it was open-sourcing.

Many of the libraries that we use at my company are open-source, but we don’t use them because of that — we use them because they are the best for what we need them to do. Sure, a company can choose to avoid open-source entirely, avoiding all such risk at the cost of accepting some suboptimal solutions here and there… but the startups I’ve been a part of (and want to be a part of in the future) would rather take that risk and manage it with a process so that they can build the best application possible.

Read Full Post »

I’ve been generally interested in both Ruby and Rails since hearing Dave Thomas speak about them at a conference a year ago, but never really had the time to sit down and focus on them, so apart from skimming through the pickaxe book I can’t say that I’ve done much.  A small part of that was the effort in setting up the development environment — getting an IDE, setting up Ruby, Rails, a web server, a database to have Rails and Ruby talked to, etc.

Deciding to pick it up again, I’m very happy to see that things have become much easier with the creation of a couple of new tools: RadRails and InstantRails. RadRails is a repackaging of the Eclipse IDE, the Ruby Development Tools (RDT), and a Rails-specific plugin, all in one convenient archive — just download, unzip, and run.  Because it uses Eclipse, it’s also easy to include other plugins for source control such as CVS or Subversion. It does require that you already have Java, Ruby, and Rails installed.  Java you’ll have to get from Sun, but as for Ruby and Rails (and much more)… use InstantRails!

InstantRails is a collection of several tools designed to help you get a Rails-based solution up and running as quickly as possible.  It includes Ruby, Rails, Apache, and MySQL — so you have your web server, database, and language to develop with. Like RadRails, the installation doesn’t require any environment changes — you can have it installed and running a sample app literally in seconds. Conveniently, it’s been recently updated to integrate well with RadRails. The only drawback I’ve found so far is that it is Windows-specific — not a problem for me as I usually develop in Windows, but if you’re a Linux- or Mac-ist that may be a dealbreaker. Curt Hibbs and Bill Walton have put together a tutorial showing how to get started with InstantRails — notable in that it doesn’t use the Apache server included with InstantRails but instead uses the built-in WEBrick server.

Between these two tools I was able to get started much more quickly than my first time around, when I had to put all the pieces together myself.  Given that I have a finite amount of time for playing around with new tools and languages, it’s very nice to be able to get quickly past the initial configuration details and focus on trying Ruby and Rails — and I hope it encourages others to do the same!

Read Full Post »

Having been generally interested in space exploration for many years, when a friend of mine suggested a road trip to go to the X-Prize Cup, how could I turn it down? Six of us went and had a blast at the competition itself talking to the various groups and watching the competitions going on, including Armadillo‘s heartbreaking third try at the Lunar Lander Challenge.  Even after the failures, though, the guys with Armadillo were very approachable and willing to chat about what worked, what didn’t, and how they had gotten this far.  While I think next year they’ll definitely nail at least the first level challenge and quite possibly the second, they’ll more than likely have some serious competition (they were the only ones trying this year).

One of the things that I found really interesting about Armadillo’s approach is how they’ve adapted several of the principles of Agile software development to building a rocket vehicle — their development process is characterized by multiple short iterations, heavily emphasizes testing, and focuses on a process where in each iteration you attempt to get some piece of incremental functionality working before moving on to the next. In a software project, these would be unit and integration tests and would result in working applications… here, it’s static engine firings and tethered test flights, and it’s more than likely to result in the first winner of the Lunar Lander challenge.
So why hasn’t this been done before, and how did they accomplish in months and hundreds of thousands what took NASA years and millions?
I think it’s entirely due to the cost of change.  A critical way in which software development differs from most traditional forms of engineering is the cost of revising your design.  No structural engineer would consider completely revising what the framework of a building looks like when it was halfway done, but this is something that often happens (for better or worse)  in software projects.  The whole concept of agility and refactoring is enabled by the fact that the cost of implementing a change can be as low as recompiling and re-running the test suite — and agile methodologies take advantage of that to “embrace change”, and believe that by slowly developing the design as you build, instead of attempting to get everything right up-front (before you’ve even started developing), that you can take advantage of lessons learned along the way.

The problem in adapting agile methodologies to traditional engineering is that in most cases you can’t afford to take your half-built building, tear it down, and rebuild it in a new manner. It’s just too expensive, both in terms of materials and in time.  With smaller projects, however, ones that are cheaper and take less time, you can afford to do this — as any shade-tree mechanic or Sunday carpenter knows, sometimes you get halfway into a project and realize there’s a better way.  When NASA built Gemini and Apollo, everything was hugely expensive.  Many if not most parts were being custom-developed and some of the materials were either completely new
or being used in completely new ways (although not Velco, that’d been invented shortly after WW2). The cost of changing the design was huge.  Team Armadillo, on the other hand, can take advantage of the huge advances in miniaturization and cost that have been made in the past 40 years. Many of their items are either low-cost and home-built, or are simple off-the-shelf parts (like the ‘brain’ of the system, a commercially-available PC104 board running Linux). The fact that they can quickly and cheaply replace parts when they break, or can even redesign (to a certain degree) entire systems means that their cost of change is low.

With a low cost of change, agile practices become practical, and I believe that being able to take advantage of that tight feedback loop — Try, Test, Fix — had a lot to do with Armadillo’s success so far. And, after all, I want them and others to succeed — they’re getting me closer to my vacation on the moon!

Read Full Post »