Good Software Project / Bad Software Project

January 18, 2013 · 6 Comments

homer1

Inspired by this post

Good software projects have clear business goals and objectives. Everyone on the team has an understanding of what metrics will be used to define success. i.e. Implementing these changes to the sign up flow will increase paid conversion rates. Bad software projects are driven by the loudest voice in the room and based on personal preferences. Success cannot be measured because it was never defined.

Good software projects are built initially for a specific target audience based on customer development and hypotheses. i.e. We interviewed 100 used car salesmen and found out their most time consuming task is following up with potential buyers after test drives. Let’s build a mobile web app to let them take notes and send follow-ups while they are still with customers. Good software projects start by doing one thing 10x better than anyone else. Bad software projects are built for everyone. These projects are incrementally better then their competitors and try to “out-feature” them. They are everything for everyone and fall short. They are built because they could, not because they should.

Good software projects have a plan to acquire users after launch. i.e. Through our landing page we’ve accumulated over 1000 emails. We also started a influencer campaign with the top bloggers and Klout scorers in this space. We’ve also set aside $2,500 to test Google Adwords and Facebook campaigns. Bad software projects rely on hope and a “build it in and they will come” mentality.

Good software projects have a shared sense of ownership and are built with passion and love. Everyone is willing to step outside of their comfort zone to learn new things and attack new problems. Bad software projects have people finger pointing, and people who live within their title and place. “I can’t fix this, I’m just a junior developer. Ask Joanne, she wrote this.”

Good software projects have teams who pay attention to details without getting hung up on them. They are able to make decisions quickly and move on. Everyone working on the project has context. Bad software projects are built by teams without expertise.  They spend weeks arguing over the shade of green on a button.

Good software projects release software as frequently as possible and get constant customer feedback. They have product owners who have a deep understanding of their users and are able to prioritize features. Everyone tests and logs feedback. Bad software projects stay in a black box for weeks and when finally released are underwhelming. Everything is equally important.

Good software projects ship, measure and learn. Bad software projects don’t.

  • james

    good article… thank you…

  • Marcus

    Awesome article!!! My company falls in the “Bad Software” sphere a little too often. But we are attempting to implement processes to help us enter and STAY in the “Good Software” sphere.

  • scott

    my company also falls in the category of bad software projects!! decisions are influenced by personal preference, everyone driving projects to what they want it to be!! it is frustrating when ppl don’t want to get out of their comfort zone its almost like walking in the opposite direction!!

  • vincenzoc

    all this is absolutely true. Greater post, thank you!

  • Steven

    my company isn’t in software, but the principles are the same. great article.

  • VED

    Could not have said it better: the problem is that one needs to have worked in several bad and great projects to truly understand the article’s content. Lately, I have been on two back to back bad projects and the project members seem to think the project is developing normal when it really is not. And all I get back when I raise a risk or concern is that I must have been spoiled on other projects. And when did projects that took six months and sometimes year get collapsed into weeks? And why are so many software being re-launched, and not just once or twice but as often as five times? And why are companies burning through so many vendors just to get a software launched? And when did JITT become a term for documentation, development, ??? And please do not be blaming Agile – some PMOs know how to implement Agile and others just turn it into some Frankenstein.