MVP Minimum Viable Product

According to wikipedia, the term minimum viable product, MVP, is a term coined by Frank Robinson, and popularized by Steve Blank, and Eric Ries. I find this to be a very powerful idea, and one that works hand in hand with using a PHP framework, such as Laravel 5.1 and Yii 2.

So what is MVP? It’s easy to mischaracterize MVP as a product with limited functions and features because while it typically does have less features than the typical enterprise application, the goal is not minimalism.

The idea with MVP is that you stand up the minimum number of features you need in order to collect data back from the users, so you can validate your business model as you develop it. You build just enough to allow yourself to follow the breadcrumbs of data, then follow that data like a compass to determine your sense of direction.

The speed at which you prototype and process this early feedback is important. The idea is to incorporate the customer feedback into the build itself, and you can only do that if you are testing and validating often enough.

One thing that’s great about this process is that it eliminates the old arguments between creative people about what will work. Instead, we simply let the customers decide.

The good news for those of us who use PHP frameworks is that they can really facilitate the MVP process, and that’s how we should think about it, as a process.

It’s a process that maps to the processes being adopted by entrepreneurs and lean startups.

Eric Ries defined 5 principles that drive the Lean Startup process:


The last one, build-measure-learn really encapsulates MVP. You might be tempted to quantify your job as programmer to simply program what the entrepreneurs ask you to do, and shuffle off the build-measure-learn concept as their problem, but doing so makes you less valuable to them.

On the other hand, if you take the time to plug yourself into their process, you’ll find yourself becoming invaluable to the enterprise. You’ll be part of the team that provides insight and clarity to the objectives, based on the intersection of design patterns and application usage patterns, the latter being provided by the customer feedback. The concepts developed in the code and the concepts of the enterprise fuse into a single entity and you will find yourself being a facilitator of this.

Leveraging the strength of a php framework can be an integral part of this process. For example, you might work for a company that doesn’t know the difference between building user RBAC from scratch and using or extending the options that are readily available to them from Laravel, Yii, and other frameworks. You can help guide them through these strategies and implementations. And if you can do it quickly, you will be their hero.

That takes us back to our php frameworks. When you study these frameworks, you can’t help but fall in love with them. There’s almost always core functionality or a plug-in to cover your requirements, so you can prototype very quickly.

The main thing to understand in a MVP approach is that it’s development on the fly, objectives change with the inflow of data, and decisions and implementations must be made rapidly. In the midst of this kind of environment, there is no difference between your love for PHP frameworks and the other tools that are available to you, such as Bootstrap, jQuery, and love of the enterprise itself. Your passion for development will help drive the enterprise.

I’m going to leave it at that. This article is meant to be a brief introduction to MVP. I recommend reading the wikipedia article and perhaps The Lean Startup by Eric Ries. I need to get a copy myself. Although I practice many of the principles, I have never actually read the book. Isn’t that so typical?

I can however vouch for build-validate-learn, though I would modify it to build-validate-succeed. Learning is not enough. Sometimes you only learn that you didn’t succeed. Those lessons are always valuable, but the real objective is success. Keep testing/validating until you succeed or pivot into something else.

Anyway, I hope you enjoyed this post. Please comment, share, and like if you can, thanks!

Laravel 5.1 Released

Laravel 5.1 is released today and it’s awesome. While there are only a few differences between 5 and 5.1, they are impactful, and really cement Laravel’s position as an enterprise framework. One of the most obvious changes is LTS, long term support, which fixes bugs (2 years) and security patches (3 years). This is obviously critical to enterprise development.

Another leap forward is the quality of the documentation. It’s incredible. Taylor Otwell wrote the documentation himself, and put the same obsessive care into the docs as he does the framework itself. This attention to detail really shows.

The first huge feature of the docs is the search window.  It’s easy to overlook, since I’m not used to using it and there is no label, but this is powerful.  It autocompletes what you are looking for and even does a good job of guessing on typos.  For example, when I typed in redur, it correctly understood I was looking for redirect.

Type in something like val and select validation.   Look at how great the Validation docs are. In the validation quickstart section, he begins with a route definition and takes you all the way through form validation, so it’s clear and comprehensive. We learn for example that all validation errors are automatically flashed to the session and are always available in the view through an $errors variable. Then of course we get a comprehensive list of validators.

If your validation requires a dependency, there is a great example, using the sometimes method to show you how to do it under the complex conditional validation section.

Another example of how thorough the documentation is the section on migrations. It’s a complete reference to:

      Creating Tables
      Renaming / Dropping Tables
      Creating Columns
      Modifying Columns
      Dropping Columns
      Creating Indexes
      Dropping Indexes
      Foreign Key Constraints

In the past I never really liked migrations, but I have come to appreciate them, especially since the workflow and execution on Laravel is so good.

The validation and migration sections are typical of the quality of the docs, I pretty much chose them at random.

Not only do great docs make it easier for beginners to find what they need, but obviously, they are a must have for enterprise development. Great documentation leads to coder happiness. Happy coders are productive coders. Productivity is essential for a successful enterprise.

Another change in 5.1 is the move to PSR-2 coding style, which is the one I’m most familiar with, so no complaints here.

Laravel 5.1 also introduces parameters on the middleware. If you are unfamiliar with the middleware class, it replaces the filters from previous versions of laravel. At first, I found this part of the structure a little complicated, but I have grown to appreciate it.

Basically middleware is a series of filters that are injected into requests via route definition or controller. They are super simple and easy to use, once you understand it, and once you see how it fits into the application structure. Not only that, but Laravel 5.1, like 5.0, has code generators for these specific classes via artisan, which will place them into the appropriate folders for you. So this helps you deal with the folder structure more easily.

While it’s true that new folder structures of 5/5.1 are way more complicated than what I was previously used to, they have had a curious side-effect. It’s actually easier for me to conceptualize or visualize the application as a whole. The discreet parts of the application make more sense to me. In the long run, the complicated folder structure makes application development easier and cleaner. You get far fewer overstuffed classes in favor of a greater number of leaner, more focused classes. It makes for cleaner code.

The release of 5.1 also includes the new @inject method for blade, which allows you to bring in a class instance from a service provider or helper class directly into your views. Normally, you would bring in all of your object variables into the view via the controller, but this could lead to code duplication. So, as in the latest example from Laracasts, if you have a stats object that you wish to use in many views, you can simply access it directly from within the view via @inject. This helps make code re-use simpler, since you don’t have to bind a view composer to a route.

Since I mentioned Laracasts, they have a bunch of new videos released today for 5.1, all worth checking out. Everyone here at work loves Laracasts.

The last new features that I’ll talk about in 5.1 are the model factories for seeding and the enhanced test integration. Model factories help automate the data seeding process, a very handy feature. It was already fairly easy to seed data and this just takes it a step further.

I’m going to defer to the testing video at Laracasts for the new testing improvements explanation, but I will say that it’s got the developers here excited about how easy it will be to test forms. It’s a huge plus.

For more info about the release, check out the Laravel 5.1 release notes.

Ok, so to wrap it up, let’s offer congratulations to Taylor Otwell and the rest of the Laravel team for releasing such a great enterprise framework. It’s through the work of teams like this that innovation and success becomes more accessible to all of us. It is much appreciated.