RSS
 

Archive for the ‘management’ Category

You don’t know when you’re done if you don’t know what done is

08 Aug

As I mentioned in an earlier blog post, we are working hard on a 2.0 version of the product. One of the questions our team is asked quite frequently is “when will it be ready?” This question is impossible for us to answer, because ready is not defined. It’s one of the dangers of working without a real spec.

There are a lot reasons why we don’t use a real spec, none of which are up to me so I’ll not discuss them here.

Whenever 2.0 gets close to what everyone thinks we have agreed on, people look and poke at it, decide they don’t like things or realize nobody ever asked for critical feature x, or it somehow didn’t make it onto our bug list, and then we have to go back and get new designs, file a bunch of bugs, and set a new milestone. Repeat, repeat, repeat. It’s not just for 2.0 that it works this way, it’s whenever you’re working without a complete spec. When the goal posts for done are constantly moving, the question of “when will it be done?” Is really a question of “when will the goal posts stop moving?”

To break the cycle, we’re picking a done date, and mandating that the goal posts stop moving some time before that date. Working towards that, we’ve submitted our “last chance” milestone, meaning after this milestone any decisions/changes/designs must be final, because we’re going to call it done when those have been implemented, or when we hit our chosen date, whichever comes first.

 
2 Comments

Posted in grooveshark, management, software engineering

 

If everything is top priority, then nothing is top priority

05 Dec

One of my heroes, Raymond Chen, writes about how he dealt with the annoying habit of management to give conflicting things top priority (here).

In the past we’ve had the same problems with management at Grooveshark. I was not clever/important enough to single handedly shape the behavior of management, however, so the end result here was that I would pick from the “top priority” list, which ended up being a list of every single thing that needed to be done, ever, and just do the ones that most interested me.

Grooveshark management is taking a new approach now, and we lowly devs are now more empowered to decide what our priorities should be. Essentially, it’s a lot like the old system, but lest frustrating for both parties, because there’s no pretense. :)

 
1 Comment

Posted in grooveshark, management

 

The pain of project management

30 May

For the second time now, Grooveshark is making a serious effort to utilize project management software.

I don’t like the new project management solution, even though it is a vast improvement over the old one, and I think I’ve discovered why: I don’t like project management. I don’t like project management because project management is not for me; it’s for managers. Managers and developers have vastly different interests. Developers want to know what bugs are in their code, what features they need to develop, a way to view dependencies, and a way to see which bugs/features are most important. Bugzilla fits those needs perfectly. Managers, on the other hand, need to make sure that they are maximizing productivity by making sure devs are never sitting idle, they need to know what is going to happen when; they need ship dates.

The thing about bug tracking is that the people who benefit from it are the same people who have to do the work. If you want to see a bug get fixed, you file it. If you want to find bugs to fix, use the bug tracker. Project management tools, on the other hand, require a vast amount of work from the people who don’t need them: developers. That drastically decreases the chances that they will be used consistently. It also means that project managers end up working against their own goal: they reduce productivity. This is consistent with Le Chatelier’s Principle: Complex systems tend to oppose their own proper function.

It’s actually a more pronounced effect than just wasting dev time on project management. At least for me, having multiple people assign tasks to me with various arbitrary deadlines tends to make me feel like I am being micromanaged, which increases stress and also keeps me from being able to focus on any one thing for long enough to accomplish much. (“I’ve been working on this thing for 3 hours and I have all these other things to do, I should put it on the back burner and move on…”)

What’s the solution? I don’t know, but a good start would be to combine project management with bug tracking, ala FogBugz, set overarching deadlines for projects, let your devs work out the details, and be flexible. Plan for other things coming up, because new and very important bugs will pop up all the time, servers will break, and meetings will happen (sadly). If your developers are good, hardworking employees (and Grooveshark devs are), they will strive to meet or exceed the goals you set for them, without being micromanaged.

 
4 Comments

Posted in grooveshark, management, software engineering

 

Development Timeline as a Contract

20 Mar

Development timelines are a contract, in many ways.

Contract negotiation happens when developers sit down with management to hash out a release date for a product or feature. As with any other contract negotiation, both sides come to the table with their own demands, and there are concessions on both sides, but hopefully when the negotiation is over, both parties can be happy with the results. It is also essential that the terms of the contract are clear: if developers and management have different understandings of what feature XYZ entails, they might think they have come to an agreement when they haven’t; this will only lead to problems later, usually altered feature sets or later release dates.

It is important to keep in mind that contracts can be breached by either party, and this is certainly the case when dealing with timelines. If either side fails to hold up its end of the bargain, the timeline will slip and the contract will be broken. It’s obvious how developers can be in breach of this contract, and they are certainly usually the ones held responsible for it, but how can management be at fault? Well, it entirely depends on the negotiation process. If, for example, management assures the team that they will have a certain server in place and ready for production N days before release, and server deployment is delayed, development cannot be held accountable for the schedule slippage. Likewise if the development team asks for feature lockdown and management continues changing the specifications throughout the development cycle.

In an ideal situation, both parties of the contract are working towards the same goal: a product that will make the company more successful. What type of product that is exactly depends on the company, but goals that any team would strive for includes an intuitive interface, a useful feature set, and a bug-free user experience. With a set of shared goals, if both parties are able to hold each other accountable and enforce the terms of the contract, the end result is usually an on time release that both parties can be satisfied with.

In situations that are less ideal, where developers cannot expect management to live up to their terms of the contract, compromises will have to be made somewhere internally. A feature will silently go missing, the product will be poorly tested, or release dates will be moved back.

 
No Comments

Posted in management, software engineering

 

New and improved Sharkbyte

05 Mar

Apparently I was not the only one who was very unhappy with the way Sharkbyte handles updates, so the Sharkbyte team has implemented a way to make sure that users always have the latest version.

It’s not perfect, but it’s a very good start.

The complaints I still have with it are relatively minor compared to silent failure, but will hopefully be addressed soon anyway:

  1. On my machine the alert dialog popped under my open windows, so I didn’t see it for a couple of hours.
  2. When the user does finally see the dialog, it’s not actually clear that it came from Sharkbyte.

I actually prefer that point 1 not interrupt my work by popping up a dialog on top of my other windows, but it would be nice if it popped up if I was trying to listen to music with an outdated version of Sharkbyte, or if it at least flashed in the taskbar to get my attention.

Complaints aside, it seems like everyone at Grooveshark is coming to realize that the user experience is paramount and that is something that I am very pleased about.

To paraphrase Skyler (since I don’t remember exactly what he said) today:

We have to remember the user; we might spend all day wrestling with SQL queries, but we have to remember that’s not what Grooveshark is about. We have to remember the users and make sure that we are making the site better for them with everything that we are doing.

Apologies to Skyler if I completely got that quote wrong. Feel free to correct me.

 
1 Comment

Posted in management

 

How to keep your users happy

01 Mar

As a sort-of follow-up to the negative example how not to keep your users happy, I’d like to provide what I feel is a positive example of how to keep your users happy.

Before I delve into today’s example, if you haven’t read Joel Spelosky’s seven steps to remarkable customer service I command that you do so now. I command it! Back? Ok, good, now you should understand why good customer service is so very important.

Today, Friday night I received an alert that a customer had a problem adding funds to their account through PayPal. It’s worth noting that I did not receive a complaint from the user. Users generally do not complain about problems with a web site; they just leave. I set up the PayPal system so that all developers would receive an email when there is an error, so that someone, anyone, whoever is in the office, will know to look into it or at least call someone who can, as soon as possible. If a user wants to give us money, gosh darn it, they’d better be able to. So when I received this alert, I ran a test charge through PayPal and was able to add funds to my own account. I looked up the error message and found no meaningful explanation for the cause. Other developers had posed on the paypal forums about this error message with no resolution to their problems.

At this point I had two problems: I needed more information to make sure the problem was resolved on our end so this doesn’t happen to other users, and I needed to make sure that we were not losing a customer as a result of this error, so I looked up his information and emailed him. I apologized for the problems he was having, admitted up front that I had never seen such an error before and asked if he could give me any additional information about what might have caused the problem. He wrote back promptly and explained that he had forgotten his paypal password and had made a couple of failed login attempts before requesting a password reset from PayPal. He finally got that straightened out and authorized the payment through PayPal when we got the error. I thanked him for the explanation, promised that we would be in contact with PayPal to resolve the issue and make sure that it doesn’t happen again, and added $10 (the amount he originally tried to PayPal) to his Grooveshark account. I suggested that if he wanted to help further diagnose the problem, he could try adding funds via PayPal again, now that he knows his password. He did so, and it worked like a charm.

Now instead of a disgruntled user who couldn’t buy songs from us and probably wouldn’t have bothered trying again, we have a happy customer with $20 to spend at Grooveshark, we received the same revenue that we would have if the original payment had gone through, and we got the information we needed to work with PayPal to get this issue resolved (hopefully). Everybody wins. Now yes we will have to pay royalties on all $20 of the dollars that he spends on music, plus the portion that goes to other users who he is downloading the music from, but compared to the cost of getting new customers, that’s actually a very good deal for us.

 
2 Comments

Posted in management

 

Music 1.0 is Dead

28 Feb

Music exec: “Music 1.0 is dead.”

Five hundred top members of the music business gathered today in New York to hear that “music 1.0 is dead.” Ted Cohen, a former EMI exec who used the phrase, opened the Digital Music Forum East by pleading with the industry to be wildly creative with new business models but not to “be desperate” during this transitional period.

Consider the statements that were made today without controversy:

  • DRM on purchased music is dead
  • A utility pricing model or flat-rate fee for music might be the way to go
  • Ad-supported streaming music sites like iMeem are legitimate players
  • Indie music accounts for upwards of 30 percent of music sales
  • Napster isn’t losing $70 million per quarter (and is breaking even)
  • The music business is a bastion of creativity and experimentation

Just within the last year, we’ve seen an array of experiments that include ad-supported streaming, “album cards” from labels like Sony BMG, and allowing Amazon to offer MP3s from all four majors. Some labels even allow user-generated content to make use of their music in return for a revenue share from sites like YouTube—unthinkable a few years ago to a business wedded to control over its music and marketing.

All of this bodes very, very well for Grooveshark, aside from the fact that we weren’t used as an example. We’ll soon be getting much more attention in that vein, but hopefully not until we’ve had a chance to improve the site in these areas:

  1. Differentiating between files and songs properly
  2. Faster loading times
  3. Better searching
  4. More user friendly interface
  5. Eliminate silent failure

So clearly, we have a lot of work cut out for us in a market that is on the verge of exploding, but if we can focus our resources I think we can be mostly there within a few weeks. Now to get management on board.

 
No Comments

Posted in management, music, software engineering

 

How not to keep your users happy

26 Feb

Tonight a new version of sharkbyte was released.
If you have not restarted sharkbyte/your computer, you do not have the new version.
If you do not have the new version, any file you try to play will appear offline, and you won’t be told why. Hopefully by the time you read this that issue will be fixed.

But in case it’s not, now you know.

This is not a good way to keep users happy, or keep users period.

Appropriate ways to handle these issues in the future:

  1. Do not break backwards compatibility every time there is a new release.
  2. Notify about and/or automatically update to new versions when they come out, like Firefox does.
  3. Notify users when they come to the website if they are using an outdated version.

Obviously these are general solutions that apply to any web desktop app, but it’s especially important if your entire site relies on that app to be working on a user’s machine. Imagine going to Google and getting no results for every search because you aren’t running the latest version of Google desktop. That would never happen, because it should never happen.

 
2 Comments

Posted in management

 

No Room for Ego

18 Feb

There’s no room for ego in software development, and especially if you are a small startup setting out to change the world, there’s no room for ego on any team.

Here at Grooveshark, we have the smartest bunch of people I’ve ever worked with (and they’re not paying me to say that), but we all make mistakes, have a bad brain day and make less than optimal decisions sometimes. When there is no ego involved, we can all point out to each other when one of us is being stupid, and we can easily own up to our own mistakes and learn from them (and make the site better), and we can ask questions when we don’t know something.

If ego is involved, it’s no longer easy to tell someone they are doing something wrong or question their decisions, because you might hurt their feelings. Conversely, if you are maintaining an ego, you’re going to have a hard time admitting that you don’t know things that you need to.

Either way, precious time and resources end up being wasted, either fixing bugs, redesigning architecture or spinning your wheels trying to figure out something that someone else probably already has the answer to.

I ask my co-workers probably hundreds of questions a day. I’m not an expert on the way every single piece of our site works and it doesn’t hurt my ego to admit that. So when I find a bug in, say, the recommendation engine, I can go over to Travis who seems to know that system inside and out, and ask him exactly what is happening. I don’t think Travis has any less respect for me for it, but now I know more about how that part works and I fixed the bug, so now we have a better product, and it only took me a few minutes because I didn’t have to analyze each line of code tracing through the object hierarchies, etc.

When we have to design an important new feature or revamp the way part of our architecture works, we have a meeting about it and everyone provides their input. We usually start out with a few different ideas and everyone argues and makes a case for their idea. In the process of doing that we change our minds and come to a consensus. Because there’s no ego involved, we’re each prepared to give up our idea if a better one is presented, and we usually end up coming up with a solution that is better than what any of us would have designed on our own.

This concept applies to other teams/departments as well. In my experience, those teams open to constructive criticism from outside the group are the most effective, and those that are least receptive to feedback tend to have lower quality solutions.

 
2 Comments

Posted in management, software engineering

 

You don’t know what you do until you know what you don’t do

31 Jan

Raymond Chen is a wise old programmer from Microsoft. He’s been in the business a long time. This is an old post of his that I have brought up at Grooveshark several times, so I figured I should post a link to it here for handy reference.

You don’t know what you do until you know what you don’t do.

I’ve seen a lot of software projects, and one thing I’ve learned is that you don’t have a product until you start saying “No”.

In the early phases of product design, you’re all giddy with excitement. This new product will be so awesome. It will slice bread. It will solve world hunger. It’s designed for everybody, from the technology-averse grandmother who wants to see picture of her grandkids to the IT manager who is in charge of 10,000 computers. It’ll run equally well on a handheld device as in a data center.

When I see a product with an all-encompassing description like this, I say to myself, “They have no idea what their product is.” You don’t know what you do until you know what you don’t do. And the sooner you figure out what you don’t do the better, because a product that promises to do everything will never ship.

 
No Comments

Posted in management

 
« Older Entries