Freedom Through Apps

Article: Freedom Through Apps: Knowing How to Iterate Apps

Becoming rich through the development of applications is a common dream. At the start of this series, I wrote how the road leads through independence. From there, I explained the idea of the lone wolf app developer. The last article was how to get folks together and do a sexy startup. However, this is the structural component of making the dream of retiring rich. It’s time to learn how to create the compelling apps that users will buy.

Perhaps the most successful mobile game of all time is the Angry Birds franchise from Rovio—a Finnish game developer. At first glance, it appears that Rovio has been making great mobile games forever; however, the truth is much different. Angry Birds was their 52nd game released. Not the first, nor even their fifth…, but rather their 52nd. Flappy Bird, another popular bird game, found its creator, Nguyễn Hà Đông, re-using a character he had created for a game that was cancelled a year earlier. Not even the titans of the mobile game market earned their chops on their first game. Instead, they had to “kiss a lot of frogs” before they found their prince.

Applications and Apps

It used to be that Electronic Arts built megalithic games with storylines and cinematography and big budgets. Today, PopCap Games (a division of Electronic Arts) builds small games to run on mobile devices. Instead of a game development cycle running years, they run months. Instead of teams of hundreds, they’re teams of dozens.

The market has changed. The market used to be that we had to invest and test to see if it worked at the end. However, today we’re focused on the minimum viable product (MVP). That is what can I get out into the market to test and let users react to it. We need to learn what did—and didn’t work when the users got it. What did they love? What did they hate?

Read more…



Article: Freedom Through Apps: Sexy Tech Startup

If you are like most developers, you dream of the idea of building the next big app that will cover the cost of your retirement. In the article, Freedom through Apps: The Road through Independence, I cover a few up-front considerations needed to begin the reality of building such an life plan. If you can’t be the lone wolf developer; because it’s too much work, or it’s too risky, or you like people too much and you want a road to financial freedom, how do you get there?

The other vision that people chase is the idea of creating a startup company, getting funding, and making it big. While certainly this has worked for some folks, it’s not the path that most successful folks take. As it turns out the hidden work of building a startup is more than most folks realize.

Fail First, then We’ll Talk

Imagine for a moment that you’re sitting down with an investor who has enough money to invest in your company. Imagine that you’re willing to give up any amount of ownership and you’re ready to deal. However, instead of the investor working on terms and negotiating for a percentage of ownership for an amount of money, you hear “Fail first and then we’ll talk.”

The reality of getting investment dollars is that investors invest in people and not ideas. They invest money where they believe that the person will make it work no matter what the cost. They invest when they believe the investment will pay off and not in a win-the-lottery type of way, but in the kind of way that they expect people will want to buy milk tomorrow. So investors are looking for two key things in a person. First, they want to know that you know what it’s like to fail. They want to know that you’ve learned what you’ve done wrong before so you know not to make the same mistakes.

Read More…


Article: Freedom Through Apps: Retiring a Rich Developer

In the first article of this series, “Freedom through Apps: The Road through Independence,” we started to look at the idea of gaining freedom from the daily grind through creating applications. We more specifically covered the idea of carving out time. In this article, we focus more deeply on how you can leverage your independence to create an app—and a company that will be your ticket to retiring rich. What does it take to set yourself up as a developer who can retire rich?

Our first view of the developer who has become independently wealthy and has retired is the lone wolf. The idea of the lone wolf is enticing because it means we don’t need anyone else to “make it big.” However, there don’t seem to be many successful lone wolves. Those who try to make it on their own often end up burned out and frustrated. One success story from many years ago is Phil Katz, who wrote an enhancement to the ZIP archive format—PKZip. The program was a success and a company formed around it and his software. However, PKZip is the exception not the rule.

To Know about Knowing

Most developers are hard wired for learning. Whether it’s a new language, tool, or environment, learning is a core part of what it means to be a developer. Most developers will initially resist a language or environment as a passing fad, but eventually dive in and learn the latest and greatest once they’re sure it’s going to stick around. We’ve all learned something that turned out to not be useful any longer. (I happen to know a great deal about sales and use tax because I needed to for a project once.)

However, when considering the lone wolf, not everything is rosy. Some of the skills that are required need a different way of viewing the word. Often, the required perspective is so foreign that it’s difficult to see how to get there from where you are. The skills I’m talking about aren’t the skills of a new language or environment; the skills I’m talking about are business, sales, and marketing.

Read more…

Developing photos

Article: A Developer’s Path to Freedom Through Apps

Rarely is there a developer I come across in my travels who isn’t interested in starting their own company and creating the next big app. Actually, it’s more accurate to say that most developers have a view of creating an app as a way to win the lottery. It’s the shared dream of retiring early, driving sports cars, and leaving the cubicle police far behind.

The good news is that the dream has become a reality for some. They’re already where we want to go—so they can help us get there too. The bad news is that the road isn’t straight and it’s not without work. Sometimes, more work than people expected. Along the way, I’ve met folks who’ve tried and failed, who’ve soared and crashed, but there is wisdom in their stories, too. In this series of articles, we’re going to look at building apps and how they can lead you to freedom or just another prison. The first stop is the road through independence.

The vision we have is that those who’ve created their apps and are living the good live starts in one of two ways. They start as a lone wolf coding through the night living on Mountain Dew and Cheetos, or they start as part of a posh startup located in a city we don’t live in who received their funding from an angel investor—who you have no hope of meeting.

Read more…

die face

Article: Six Things Every Developer Should Know to Stay Current

Our technology world is spinning faster, and sometimes trying to figure out what you need to do to stay relevant to employers and to continue to enjoy being a developer is difficult. It seems like every day there’s a new release of a language, library, or technology that you need to know to be at the top of your game. With that in mind, here are six things that you can do to stay current.

1. Protect Your Passion

You became a developer for a reason. You’re good because you love it—or at least you did at one time. If you want to be a great developer, you have to maintain or regain your passion for the craft. This can mean developing a game in Unity “just because.” It can mean developing an Internet controlled toaster with a Raspberry Pi II.

The point isn’t what you do to have fun with your development again—the point is to have fun. The best developers are those who’ve got a passion for their craft. If you’ve got it, keep it. If you’ve lost it, find it.

Read More…


Article: Validating Software Requirements

Unit testing and test driven design don’t help you if your requirements aren’t right. It may be that trying to create the tests will expose that you have a problem but wouldn’t it be nice to know that there are gaps in requirements before you sit down to write code? Although it’s impossible to get perfect requirements, most developers would love to get requirements that are better than what they’re getting.

Whether you’re getting requirements from a business analyst or you’re creating them yourself, here are a few simple tips for ensuring that your software requirements are right. These tips are pulled from my Pluralsight course Gathering Good Requirements for Developers.


Here are some things that you should check to ensure they have been covered:

  • Are all the stakeholders represented? Have you received feedback from all of the parties impacted by the solution?
  • Do you have functional requirements for all user requirements? Were you able to translate all of the high-level user requirements into specific requirements?
  • Do all of the events that the system must respond to have responses? If you look at all of the events such as approvals, rejections, creations, and the like, do they all have a system response?



Article: Yammering About Development

Years ago, we heard about a movement in software development that was more about individuals and interactions than processes and tools. It was about responding to change and not a rigid plan. Of course, I’m quoting from the Agile Manifesto.

Agile development didn’t spring to life overnight, but slowly and over time we’ve adapted as an industry a more agile approach to how we develop software. A similar change is happening in the way that we communicate, and it’s happening in the same fits and starts that agile development initially had. The change is about collaboration, not negotiation. It’s about getting things done rather than having documentation. The changes that we’re seeing in communication follow the same openness and transparency that created agile nearly 15 years ago.

One of the tools that stands to change the way that we communicate is Yammer. Microsoft purchased Yammer in 2012 and has been integrating it into its products and services, creating a future that includes Yammer integrated into the Office applications we use every day.

But the question is how does a mass-market enterprise social tools help developers write better software? Clues are in how Yammer aligns to the direction we’ve been headed for years and what we’re already doing in person for agile development. Clues can also be found in the way that we collaborate outside our enterprise, despite Yammer being described as the enterprise social network.

Read more at:


Article: Eliciting Vision through Exercises and Games

The process of developing detailed requirements – or even a well-articulated vision – can be an excruciating process without the right facilitation techniques.  In a broken process the person gathering requirements doesn’t know what to ask and those who want the solution have a hard time articulating what they want and need because they don’t know how to share their thoughts with someone from the outside.

Facilitating a discussion takes skill and curiosity, however, in many cases that’s not enough to convey the richness of the desires of those who want the solution.  What’s needed is a framework for success.  Forming a framework based on the learnings of knowledge management for the last 20 years and instructional design of the last 50 or so years creates opportunities to gather requirements and vision more quickly and with greater vibrancy.

Fish and Water

If fish could talk and you asked them what water was like, how might they answer?  They’d probably answer the same way we’d answer about air.  “It’s the stuff you’re in.” Or perhaps, “It’s always there.”  Because fish have never known anything different, it would be hard for them to articulate an alternative reality.  Likewise, if a fish were trying to describe the properties of a house, it’s unlikely that they’d mention that it has to be something that will stay together in water – because from the point of view of the fish that is obvious.

This is the fundamental challenge of eliciting vision and requirements.  When you’re “in it” you can’t see it.  It’s up to the person gathering requirements to create an opportunity for the person with the knowledge and vision to get outside of their environment and their standard ways of thinking long enough to be able to communicate the obvious.

Read more…


Article: Eliminate Costly User Experience Mistakes

Far too many web site design projects are plagued by continuous changes to mockups, or changes to the user experience after it’s already been implemented. While seemingly inevitable, these changes are both costly and unnecessary.  Leveraging a staged approach to development of the user experience can reduce costs, frustrations, and time.

The process revolves around the idea that you move from the least specific to the most specific user interface while covering both the static – what people see – and the dynamic – how they interact.  The process outlined below is designed to continuously elicit requirements and improve understanding earlier in the process – with less investment.

Projects that attempt to skip the steps outlined here often go directly to the mockup step and end up in countless iterations because there’s a lack of clarity about what the end goals are.  This lack of clarity makes the mockup the virtual dog chew toy, as one group struggles to move the mockup closer to their vision.  Ultimately, another group sees the move as moving away from their vision and they attempt to pull it back.  By progressing through a rational design approach, the unnecessary work of continuing to develop iteration after iteration can be eliminated.

Read More…


Article: Setting Goals with Conflicting Stakeholders

Getting everyone to agree on goals is a challenging undertaking in any organization.  Different stakeholders necessarily have different concerns and perspectives.  Those differences lead to a desire to have different goals for a project, an initiative, or an organization.  Getting everyone to understand those diverse perspectives and interlocking constraints is never easy; however, there is a technique which makes the process easier.  The technique of Dialogue Mapping creates an opportunity to reach a shared understanding of a wicked problem.  Many organizations face wicked problems – even if they aren’t aware of the problem’s wickedness.

Achieving shared understanding through the process of Dialogue Mapping leads to the opportunity to develop an approach to change the problem.  This is the heart of setting goals as a team – developing a shared understanding of the problem and developing a set of goals from that shared understanding.

Wicked Problems

Horst Rittel first used the term wicked problems to discuss problems that have a set of interlocking constraints and have no stopping rule.  There’s only better and worse – there is no right and wrong.  His experience was urban planning, where you can’t test the impact of a change without doing the change.  You can’t really see how a new road will impact a community until you build it and once you’ve built it you can’t un-build a road easily.

Wicked problems are really very large systems or, more accurately, sets of interconnected systems that operate together.  Because of the complexity, there’s no straightforward way to view the problem or to design a solution without the risk of introducing unintended side effects.

Read more…