You’ve got a new feature to complete or maybe you’re even starting a new project, yet you’re not sure how to start. Should you use RxJava? Should you make sure your app conforms to the MVP pattern? Should you create custom views for everything? Should you use fragments? What about testing? In this talk Donn will explain how a few simple tools can help you slice through the thick wall of analysis paralysis so that you can ship on time and with the confidence that you did the right thing and used the right tools.
Introduction (0:00)
Minimum Viable Development is basically a collection of soft skills that allow you to get stuff done, ship on time, and stop fussing with “analysis paralysis”. This won’t be a presentation of code; these are tactics you can use to help you ship faster and on time.
Paradigm Shift (2:49)
The first thing we can do to ship on time and get stuff done is to create a paradigm shift in our minds. Most of what inhibits us from getting things done is mental. There are technical limitations in getting things done, of course, but we are faced with mental limitations as well.
There are also external factors we’re not familiar with: questions regarding whether to use a particular framework, or reading about what the community has to say. With these issues in mind, we come to Minimum Viable Development. It is using the minimal amount of time and effort to accomplish a development task to basically move the business forward.
Perfectionism (3:43)
Perfectionism can prevent Minimum Viable Development. We’re all guilty of this. Spending time researching maybe a design pattern for instance, or maybe you looked at RxJava, wondered if you should be using Flow or Mortar, and not using fragments (because they’re terrible). Or, if you’re using enums for performance. Too much of this can lead to perfectionism.
As an example, years ago when I started consulting for an insurance company in Minnesota, I spent four days implementing a simple dropdown list. It was a simple UI implementation. The reason why it took so long was not because I didn’t understand what I was doing, but that the the code base was spaghetti code. I proceeded to talk to one of the architects about this, and complained that the codebase was absolute garbage and that it had to be rewritten. He responded saying that the code actually generates $6M/month in revenue for the company, that it employs all the people in the surrounding buildings, and that it’s actually not garbage.
That killed my perfectionism, and it was the beginning of my paradigm shift to where I am now.
Analysis Paralysis (6:36)
All of my perfectionism led to this humongous problem with “analysis paralysis,” or analyzing too many inputs to determine a particular output. You can’t decide what you’re going to do, so you spend all of your time reanalyzing all of those inputs and not doing a damn thing.
Android dev examples (7:08)
Q: Should you use fragments, custom views or something like Flow and Mortar?
I use fragments. One of the big reasons is because I need the application code to be maintainable. As a consultant, I have to walk in and deliver something that can be maintained by the next developer that shows up.
Q: Should I rewrite my entire app to use Rx?
It depends. Over a year ago, I was working on an application that had an API where all the calls were AIDL services; everything was asynchronous. Depending on the call or the configuration, we could have different asynchronous calls that were co-dependent before you can renew the screen. I tried doing this manually to great failure, and this was a perfect example of an Rx case.
Warding Off Analysis Paralysis (9:51)
How do you keep analysis paralysis at arms length? My recommendation is before you make any type of development decision, you need to ask yourself: is this going to enable me to ship faster? Furthermore, there’s an ancillary question you also have to ask: does this enable the code to be maintainable?
If you’re a very small team, and if someone doesn’t know of a particular framework or library used, that could be an impediment and slow you down.
Is Shipping Faster Really the Only Goal? (10:58)
Depending on the type of company you’re working for (small start up with limited runway vs. a Fortune 500), you have different goals and a completely different set of parameters that you can work with. The type of business you work with determines how you should act as a developer. The key is to think like a business owner. When I talk to CEOs and founders, I’ll typically start digging into what they’re trying to accomplish with the application, what the timeframe is, what are the business plans, etc.
Everything is an experiment (13:29)
When I worked on Groupon’s mobile app, I implemented a navigation feature that I spent two weeks on. I became obsessed with it, and I was proud of it. About a week and a half, later the product guy came to me with some news. They had A-B tested my feature against the original navigation, and mine completely tanked.
That moment was another turning point in my career. I realized everything I did was an experiment. I immediately learned not to attach myself to the code, because eventually it was going to get thrown away.
Tactics to Ship on Time
Time boxing (17:05)
Time boxing is assigning time-bound parameters on every task that you do. It could be adding new features, or any type of A-B test. It can also be used in day to day life; suppose you have five tasks to do, and you assign a time value to each one. At the end of the day, you’ll find that you’ll have gotten three to four of those tasks done as opposed to just one by spending too much time on any single task.
Location-oriented development (19:33)
This goes with time boxing. You assign an amount of time with a particular task, but you have to finish the task while at a specific location. This can be a meeting room or on the couches in your office. You can also do it at a coffeeshop, or at your house. There’s psychological proof that if you move out of your normal location, you become naturally more creative due to the environmental change.
Meetings are no longer than 15 minutes (21:04)
The best standup meeting I ever attended was at a company called MarketWatch. If you were late to that meeting, you had to pay a dollar to donate to charity. Plus, you only had 60 seconds to say what you needed to say. If you went over, you’d cut off and be expected to stay later.
I often refuse a meeting for the sake of making a decision on something.
There’s a great essay by Paul Graham called Maker’s Schedule, Manager’s Schedule. He writes about how creative people need large chunks of time to get things done. So, if a meeting occurs in the middle of the day, decline it if you can. Try to convince your boss to move these meetings to the beginning or end of the day, and you will be much more productive. That way, you can time box, and you can actually start moving to different locations and getting more stuff done.
Get Creative - Think Outside the Box (23:46)
I worked on a product where the app hooked up to a sewing machine with a REST API on it, but because the development environment was complex and many people were often developing or testing against it, it would not always be available, or would reboot. Initially, I wasted six or seven hours a day trying to connect to it.
To get around this problem, I wrote a mock web server with with Node.js running the hapi framework. I manually tested it using Chrome and Postman to simulate the sewing machine API. I was quickly developing faster than the other teams, and eventually the project management teams asked for my Node.js server that I built so they could give to the iOS teams because the firmware updates were coming too slow, and the device wasn’t working the way it was designed it to work.
Use What Works - Use What You Know (27:26)
The moral of that story is to use what works, and use what you know. This also goes for a particular language: maybe you don’t know Node.js, but you know Python, and you know the Python frameworks. Use that. If you know Rails, you should use Rails.
Android Libs That Help Me Move Faster (27:52)
Should you use these, or a combination of these? It depends. If any of these will enable you to ship faster with more maintainable code, use them. If it doesn’t, then don’t use it. Use what works.
Q&A (29:33)
**Q: Sometimes shipping faster comes at the expense of not being able to ship as often. It seems that shipping faster sometimes implies taking on high amounts of technical debt. How do you manage that? **
My number one recommendation is testing. Even if you can’t get a full unit test around it, if you can get a functional test over it like Espresso, you’re covering your bases to make sure that that functionality works.
**Q: How do you go about evaluating the trade off of implementing a design that needs to be compromised in its implementation, versus doing it fully? **
That’s one of the things that ends up coming back to a lot of the product owner decisions and a lot of product owner discussions that I’ll have. If the business owner says, “I want to ship this, that’s the way it is,” I can let them know I don’t agree with it, but then we move forward.
About the content
This content has been published here with the express permission of the author.
