The Developers death call.

 

MVP Software Development. No, not Most Valuable Player. In tech-talk, it stands for Minimum Viable Product. It’s something that is such a simple concept, yet everywhere I turn, I run into a roadblock with developers trying to create the next Picasso instead of the simple coloring book.

It seems like these articles are everywhere. How is it that it doesn’t stick with developers? It could be that these articles are catered towards me and not to the all-encompassing developer community. I don’t think that’s 100% true. So, why is it that developers hear it but don’t want to follow it?

Digging Behind the Developer Mindset

I think at one point in our careers, we’ve had to serve as psychologists and really get into the mind of the developer. From thoroughly attempting to unscramble their brains, I’ve extracted the following few core traits that seem to drive most developers:

• Developers love clear and complete requirements.
• Developers want to know how the entire application works. It gives them comfort.
• Developers are proud of the work that they create.

We’ll stick to those three observations since we can list developer traits all-day-long. These few traits, I believe, are the issue. I’ll explain shortly.

What Does the Company Want?

This is the big question that you, as a developer, have to keep asking yourself. If it’s not clear, ask upper management. Is the goal to produce an application as quickly as possible or is the goal to produce a near-perfect, almost completely bug-free application?

 

 

If you’re working for a bank, I would definitely encourage the near-perfect application approach. If you can, pitch and/or incorporate Test Driven Development. Make sure that you have strict testing in place.

However, in most companies, what matters the most is getting the product out the door for various different reasons. Sometimes the startup just raised funding and is eager to release the product for testing so that it can go through another round of funding. Other times, a private equity company purchased a company and wants to make it as marketable as possible in a relatively short period of time.

Even if it’s a private business, most of the time, individuals want the product out so that they can start making money off of it. If you’re building an e-commerce store, do you want to nail down every single possible edge-case or do you want to start selling products online as quickly as possible? From a business perspective, I can tell you that speed outweighs perfection most of the time.

Your Traits are the Issue

Developers are proud of the work that they create.

I’ve been there personally more times than I can count. You’re so proud of the code that you’ve written because, well, it’s something to be proud of. Not everyone can write code as cleanly and as efficiently as you can. Every line is optimized. Code is separated out for ease of future maintenance. Testing is implemented and any small possible edge-case is addressed. Your application is responsive from 10px to infinity px.

And yet the client, or your company, keeps asking, “okay where’s my product? What do you mean you’ve been working on it for weeks and it’s all backend work? Why is it taking so long to create a simple 2-page site?”

It’s this pursuit for perfection that actually has the opposite effect than you intended. Instead of being praised, you feel unappreciated.

Developers want to know how the entire application works. It gives them comfort.

It’s an absolutely frightening experience to sit in-front of a massive application and not understand how it works. You need to change the date-format on a generated PDF, yet you’re watching a 6 hour tutorial on the obscure framework that’s already up and running because it came with the Docker file. You know what you have to do, yet you feel the urge to learn this new environment fully before proceeding any further.

You may think this is part of development, but you have to remember that you’re working for a company. If you’re working for an agency, how will they justify that it’s going to take 16 hours to change the date-format on a PDF at $200/hr? Even if they can, which is fantastic, your boss will be 100% more impressed in your ability to do this in 1 hour and move you over to the next SOW.

Developers love clear and complete requirements.

Who doesn’t love clear and complete requirements? Everyone does. But you have to ask yourself the MVP question: is this an MVP application or am I required to make a perfect application? If it’s an MVP application, then use your best judgment. If you have a good project manager, he or she will be able to relay to the client (internal or external) that their new request is out of scope and that they’ll have to pay more money to get it there. If the application is not an MVP application, then you ask those questions and hope that your company gets a proper BA.

Be Prepared to Always Throw It Away

This is the best type of mindset to have. You as a developer are getting paid to produce code. If the person paying your company says, “you know that’s great, but I want to start all over,” that may seem like bad news, however, it is music to the business owner’s ears. They get to create an entirely new SOW and charge the customer $200/hr over-and-over again.

Developers get way too attached to the code that they produce.

I’ve heard developers say, “but this is my baby.” That’s way too much personal investment into the product that you’re creating. Every profession enjoys the finished product; developers take it to a new level. There have been instances in my career where I’ve watched developers quit because they’re moved to other projects or where the client closes the business and can’t fund the project any further.

To use a non-programming example, imagine that you’re a home-painter. The client states that it doesn’t have to be perfect, just quick, since he has kids that don’t pay attention to the walls and has some friends coming over later that week. He’ll pay you the exact same amount of money. You finish quickly, get your hefty paycheck, and move on with a smile on your face. A week later, the homeowner calls you and says that their child went to town with a marker and wrote over every surface that you just painted. They’re asking for a new quote.

Do you think the painter is furious or excited? If you think excited, you’re right. Did the painter insist that he needs to paint everything with a roller vs a spray gun? No. He just completed the job and got his recurring customer.

Developer Frustration

I’ve seen developers voice irrelevant concerns during business meetings that do not benefit anyone.

“I just don’t think that this design is the image that the company should be striving for.”

This design has been presented to the client. The client gave feedback, adjusted it with the UI/UX team, and now you feel like you should voice your opinion to the client? Clearly not your place to speak-up about it.

Like any job, you have the option of moving to another company that focuses on stringent requirements gathering, TDD, and code perfection. These are your Amazon’s and Google’s of the world.

I always encourage developers to have personal projects that they’re proud of. Even share them with the developers on your team; it’s fun. If you get attached to the code that you write for someone else, it’s not going to end well. You and your employer will constantly feel frustrated, and that’s not good for either of you.

MVP Software Development Definition

MVP is a tricky concept to gauge. I’ve seen MVP’s being defined differently by different clients:

• Few features, but absolutely perfect. All edge-cases addressed.
• Many features, but with a bug-level tolerance. Knows that there will be bugs that need to be fixed.

Realistically, you have to know what the bug-level tolerance is for that client. Once you know that, you can tell them whether the application is an MVP or not.

Final Thoughts

Don’t get attached to the code that you write for others. Understand when the application is an MVP and strive for speed over absolute perfection. It’s good to be organized and complete. Just remember that you should always opt for creating the simplest model to release to the public, unless otherwise stated by the company that you work for.