Cheap is Expensive

Cheap is Expensive

The common law of business balance prohibits paying a little and getting a lot – it can’t be done. If you deal with the lowest bidder, it is well to add something for the risk you run, and if you do that you will have enough to pay for something better.

Attributed to John Ruskin

The cheaper the software development is, the more expensive it will be. When people seek to develop a product, it can be hard to understand all the costs that go into it. Software development can be like an iceberg in which 90% of the structure isn’t visible to the end user.

Beyond wanting to retain as much money as possible, cheap development can be appealing because it can seem like:

  • Development can occur anywhere
  • The software functions are simple
  • When the software is completed, other, more visible “higher value” items can progress
  • Software development isn’t that hard
  • Development really can occur anywhere. The problem is that accountability can be hard to ensure from a distance. When you don’t have the ability to directly supervise the hiring process, training, and code quality you have no way of knowing what you’ll really get. There are things you can do to mitigate the uncertainty that occurs with remote or offshore work, but they cost money and time and require expertise in software development. If you don’t have someone on your team with that expertise, remote/offshore development is a huge risk. Supervising a remote team is not the same as supervising a team on-site.

    Simple does not mean that a function is easy or fast to make. A really thorough exploration of the implication of the product can show the unintended consequences and supporting structures to operationalize the features. If there is any data that is supposed to be stored and retrieved, then your product will need some sort of storage and database.

    If your “high value” items are built on a fragile piece of software, then that value will quickly be lost as it breaks and loses customers or never functioned in the first place. You can’t rob Peter to pay Paul. That never turns out well.

    It is entirely possible for a developer to put a pretty face on a project to cover a mess of chunks of broken code underneath. Worse than that is a product that functions at the moment of release, but would require a complete rewrite to update because the developer didn’t architect the project well. Yes, many people can write some code. That is not the same thing as architecting a new product.

    Software development, like a lot of skills, is progressive. When you hire an inexperienced developer, you are paying for their education as much as you are their code. That balances out on a sufficiently large team and is part of the normal arc of growing new members of any profession. If you are going the cheap route, you’re probably going to be working with more inexperienced developers and that will be reflected in the ultimate cost.

    We’ve seen projects in which the initial development was an oozing pustule of code with functions distributed widely throughout because no one with sufficient expertise thought through the architecture and the implications for each of the functions/features upon it. This code quickly drags down the whole project when later developers attempt to update or add a feature and find they can’t because the scattershot code can’t be modularly replaced or improved. You can’t remove just the tumor, because the cancer has spread.

    Even worse than that is when a business falls into the sunk-cost fallacy and just can’t let go of some really nasty and fragile code. Rather than scrap it and start over, they spend an insane amount of money frankensteining more code on top of it to keep it limping along.

    The time you spend untangling a poorly developed product and repairing it costs more than the expense of the developers to test and correct the code, it costs customers. You lose revenue the product would have earned in the delay coming to market.

    There is a mistaken impression that producing software is so easy that high school and college students working alone are creating billion dollar companies. It is true there are prodigies; rare individuals whose monomaniacal devotion to a single product is the foundation for something larger. Though even they had early supporters and funders to enable their seed of an idea to scale.

    Even though finding a bargain on development is a bad idea, there are still many ways to prevent your project from bleeding money.

    Be wise about your development expenditures:

  • Map out the functions of your product to prevent wasteful redevelopment and inadequate architecture.
  • Learn about the process of software development to become an informed consumer so you understand what the developers are doing if not how they are doing it.
  • Have a software development-specific contract; buying software development is not the same as other services.
  • Get clear Statements of Work that show exactly what will be developed and what that code will do.
  • Have highly specific Acceptance Criteria and a plan for remediation if the software doesn’t meet that criteria.
  • Being wise about your expenditures will save you the costs associated with being unprepared and uninformed. Be frugal, but not cheap.

    Cheap is expensive, expensive is cheap.

    App Map

    App Map

    Not to be too much of a downer here, but you aren’t psychic.

    Since you are not psychic, you will have to communicate your app idea to others using words and pictures. You are going to need an App Map.

    Your App Map is a way for you to visualize the different features and how they connect.  It shows others what you want your app to do and why.

    There are a lot of different ways to plan your app: App Map is ours.

    Step 1: Problems and Solutions

    Too many apps are a solution without a problem or have a solution that doesn’t match the problem.  Having a clear vision of the why and what of your app prevents this.

    Get some stickies and/or some 3 x 5 note cards and painters tape.  This allows you to have a way of re-arranging ideas quickly.

    Get a nice big patch of empty wall or window that you can use as your workspace.  It helps if you have a space that isn’t on the same wall as doors that open to the outside or are in rooms that lots of people travel through.  You don’t want things flying off the walls and getting rearranged unintentionally.

    To begin, write on a large piece of paper the problem your app is trying to solve and tape that high on the wall.  Next to that write how your app will solve it.   Write big enough that you will be able to read it both from a distance and in a picture later.

    For example, if you were making a traffic navigation app, your problem might be: There are no navigation apps that show how to get to places using only even numbered streets.   Your solution would be: app will display directions between locations using only even numbered streets.

    Do you see what we did there?

    There is a clear problem statement. 

    The solution solves the problem.  

    The solution is directly related to the problem.

    Next, you are going to write out the main things that the app will do in a row. Below each of those things a lot of additional things need to happen.  For our pretend map app, which we’ve decided to call Even Streets, it might look like this:

      • Identify even numbered streets on a map
      • Give directions list
      • Show map of directions
      • Audio cues for directions
      • Show traffic jams and accident

    Below each of those things a lot of additional things need to happen.

    Identify even numbered streets on a map

      • Have a map
      • Highlight even numbered streets in green
      • Show all other streets as grey lines

    Give directions list

      • Show every turn on route
      • Show every street on route
      • Show distances traveled on each street
      • Show the name of each street
      • Be able to slide between list and map picture

    Show map of directions

      • show map with route highlighted in blue
      • Have arrows pointing in which direction the person should go
      • Map can be made larger or smaller by pinching screen
      • Be able to slide between list and map picture

    Audio cues for directions

      • A bell tone will sound when a person gets within 100 feet of a turn
      • A voice will read directions when a person gets 90 feet from a turn
      • Voice will state what next turn or direction is after a turn has been made
      • Voice will report if there is an accident or traffic jam
      • An alarm tone will sound when the app picks up the signal of a traffic jam or accident report
      • Voice will announce re routing when it occurs

    Show traffic jams and accidents

      • Traffic jams and accidents will be shown in red

    Re route when a wrong turn is taken

      • Show a new route when a wrong turn is taken to get back to even numbered streets as quickly as possible.
      • Show new route on both map and directions list.

     

    Well…

      • How much map should be shown on the screen as a default map size?
      • What is the maximum and minimum map size?
      • Is it a male or female voice?
      • What kind of tone?
      • Can you select the tone type?
      • Can you silence the tone and keep the voice?
      • Can you silence the voice and keep the tone?
      • Can you mute both the voice and the tone?
      • What constitutes a traffic jam?
      • How much slower than traffic usually goes does it need to be for a jam?
      • Where are you getting the traffic and accident data from?

    See how this can get complicated?  How will each item work?  And then what?  Ask, “And then what?” until you’ve got no more what.

    Step 2:  User Stories

    Next, we are going to make “user stories.”  User stories are a way to explain in a single sentence the relevance and need for each feature.  If a feature is not relevant or needed, cut it.   This is really hard when there are things that are super cool but serve no purpose.  Even if you waaaaaant it, how much money are you willing to pay for something that doesn’t really do anything?

    To come up with the stories you are going to play a game of Let’s Pretend.  You are going to pretend to be:

      • An app User
      • A Developer
      • An Administrator/Business Owner

    You are going to create user stories for each role, with at least one user story on each feature.  You are going to come up with statements that follow this formula:

    As a ________, I want  ____________, so that I can ____________.

    As a User, I want the app to alert me with a tone prior to a turn so that I can be prepared to make it by being in the correct lane.

    As a Developer, I want to know the parameters for a traffic jam so that I can set them.

    As an Administrator… wait a minute, what if there isn’t anything on the map that an administrator would want? Maybe you should think about that. What would you want/need to know as the app Administrator?  What functions would help you measure and improve performance?  What do you need to be able to bill/make money off of the app?

    Step 3: Narrowing it Down to MVP

    Now that you’ve played this game of Let’s Pretend and gotten your user stories up, your App Map should look pretty full.  You’ve probably had to move and expand it a couple of times.

    Take enough pictures to clearly show each of the parts of the app so that you could clearly read what is written on each post it/card.

    What you’ve got on your wall is a fantasy.  It’s what you would do if you had unlimited funds to spend on getting your app made.  You aren’t going to get the fantasy.  Or, as one of our clients once said, “I feel like you’re telling me I’m not going to marry a supermodel.” Guess what, you’re not.  But that’s ok.

    Every single post-it/note card on that wall represents money.  Money gets wasted when features (that’s the stuff on the post its/note cards) turn out to not be the ones the app needs to be successful.

    How can you possibly know which ones will be successful?  You don’t.  You’re going to want to test it out a little bit at a time.  You’re going to start your app with the smallest possible piece of it that you can make.  The most bare bones skeleton of an app.

    What is the one thing that if your app doesn’t have this, it can’t exist?

    What is the feature that best solves that problem?

    Once you’ve identified the core functions-your first release- of the app, pull those to the far right or left of your wall.  Put a piece of tape between it and the rest of the feature sets.  Take a picture.  It is your Minimum Viable Product (MVP).

    Let’s say that by some miracle the first release of your app was profitable.  You would use the money you made in your initial release to fund a second round of features and improvements.  The money you made in your second release then will fund the third, and so on.  What would your first release be?   Group those portions of your App Map and take pictures of them.

    Really Do It

    There is no App Fairy.  Your app will not magically come together just because you clap your hands and believe.  The more you’ve thought your app through before you go to a developer, the clearer you can communicate that process, the better your chances are of actually getting the product you both want and need.

    This seems very simple, but like most simple things, it is crushingly hard.  Don’t give up, do it anyway.

    Market Research

    Market Research

    A lot of people have a great idea for an app based on an experience they had.  They assume that other people out there will have had the same experience too.  They’re probably right about that.  There are people who have great app ideas, really clever solutions. The problem is that their solution doesn’t have a big enough problem. No one else cares.

    Market research is figuring out a few key things: 

    • What related apps are already out there in the marketplace
    • Who are your potential customers and what are their demographics.  
    • What do your customers want
    • What are the gaps in the marketplace given what people want
    • How much are people willing to pay for that thing they want

    Google your app idea to get a snapshot of the marketplace.  As you Google search Amazon, Google Play, and the iTunes App Store, you’ll start to form a picture of the types of things that are out there. The market may be flooded with things that do ABC, but there is nothing yet that combines ABC with XYZ.  Or, you might find that while everyone uses a few products that have covered the marketplace, that no one particularly likes them.  They are clunky or expensive.

     

    Easy to use, but missing a few key functions.  Why can’t you choose how items are sorted?  Why is this so slow to send updates to my phone?

    I would then look at what the different apps did, making a table of the app names and the features, checking off the features that the apps had.  I would be adding a column every time I discovered a new feature. I would then have a list that showed what the apps were and what they did.  It would quickly become clear if there were any gaps in the market.  It would also become clear if the market was already saturated.

     

    I would want to know what the number of users/downloads are for a given app.  I would think about what combination of features/price/design made an app more or less popular.  In the example above, there seems to be a connection between the cost of the app and the number of users/downloads.  However, if you were to look at the comments in the app store, you might find that it had to do with the design of the app and how “usable” it was. How many stars does the app have?  People like apps that are free, easy to use, and that don’t break down.  However, depending upon the type of app you are planning, you may find that you get more people who would rather pay for high quality app with no ads than get it for free with ads.  There is a lot of research on price sensitivity that you can Google for.

    Once you’ve looked at the market, you want to know who your average user is.  Google for information about who uses the types of products that your idea touches.  For example, if your app is about auto parts, what are the demographics of people who purchase auto parts?  What do you need to do to appeal to them?  Google for the latest information about how many people of of the people in your target demographics- ages, income brackets, and locations have smart phones and if they are more likely to use Apple or Android products.

    Knowing who your target audience is for your app is a big deal.  The words you use in your app, the colors, design- really everything about the way your app looks should be influenced by who your average user is.

    Don’t assume that you know what your audience wants.  Your idea may solve a problem that no one has or cares about. Your solution may even be worse than the problem in the eyes of your average user.  How can you find out if your app even has a market? If you have done your Googling and read through comments on the app stores, you’ll find themes in what people complain about. The comments on app stores are like a free focus group that you don’t have to feed. If everyone is wishing that the most popular app currently out for your idea worked more reliably, or did a particular function, that should tell you something about what people want.

    An obvious and unfortunately overlooked way of learning what your audience wants is to ASK THEM.  Get a small group of potential users together, buy them pizza/donuts, and ask them some key questions:

    • What is the most painful part of the problem?
    • What do they do when they encounter the problem you are trying to solve?
    • If they could come up with a solution to the problem, what would it be?
    • How much would you pay for this on a one time/annual/monthly basis?
    If you ask just a few open ended questions, you should get a lot of data about your topic.  Do not underestimate the power of sharing food to create a relaxed environment.  Sometimes the most insightful comments and observations come from the casual conversations that people have between the questions. If you get a group of potential users together who fit the market demographics, and they have no interest in your idea, or if they don’t think that your solution actually matches their problem, that should tell you it’s time to take a step back and rethink your app.  That is ok.  It is better to know this before you develop your app rather than after you have spent tens of thousands of dollars.  If your feelings are hurt by an uncaring market, it is likely that your pride will recover a lot faster than your bank account. Market research doesn’t guarantee success, but it can prevent disaster.
    GOOGLE THAT IDEA!

    GOOGLE THAT IDEA!

    As you are sitting here reading this you may be confident that your app idea would be an amazing thing that the world needs and will pay you well for…

    Google that idea!  

    Your big idea may already be someone else’s successful business. We’ve had to break it to many potential clients that their app already exists.  That is the most ethical thing we can do for a client as it provides them the opportunity to approach their idea from a different direction.

    People often think that because they’ve never seen an app or a product, that it must not have been made yet.  That may not be true.  The world is a big place and your experience is limited by where you live, where you work, what tv you watch, what you look at on the internet, and who you talk to.  Just because you’ve never heard of XYZ, doesn’t mean that people aren’t already using XYZ.

    Check the Google Play store; check iTunes App Store.  Google your idea using several different search terms.

    For example, if you have an idea for a music app that mashes up songs, you would start by searching “song mash up apps.”  Then at the bottom of the first page of your Google search, Google will suggest some alternative search terms. Search those terms!  Then think some more about other ways to describe your app idea and search on that.
    The more you know about what other products are out there that are similar to your idea, the better you can hone your idea in on a gap in the market.  How could your idea be different than what is already profitable?  What need remains unfilled?

    It shouldn’t be discouraging that products similar to your idea already exist- quite the opposite- it shows that your idea has customers.  

    If your idea is connected to a tangible product or hardware, search Amazon.com for it as well.  This is important market research. Think of it like a free focus group.  What are people saying in the comments?  What do people like/dislike about products that have apps connected to them?

    If you search the Google Play store and the iTunes App Store and you find apps for your idea, what do the reviews say about the existing apps?  Do people complain about the way the interface works?  Is that something you could do differently and better?

    Your time and money could be saved with a simple Google search.  It is the least expensive and fastest thing you can do to test your app idea.  We highly encourage it.

    Testing: Skipping this is VERY Bad

    Testing: Skipping this is VERY Bad

    Calculate what you hope/expect your product to make. Now imagine 90% of that profit being cut out because the first 10% of customers rated your app poorly. Now you have the value of Quality Assurance (QA) and Usability testing. You really can’t afford not to do testing.

    Despite the high stakes, testing can be an undervalued activity in software development. There is a temptation to leave it until the very end, or worse, to let the customers do it. Assuming that the software engineers will make sure their code functions as they write it and that will be sufficient is a great way to connect with disaster. Many teams don’t even consider usability testing at all.

    One of the cheapest and most powerful things you can do for your product is to test usability before you begin programming. Create mock ups of the screens and print them out and show them to a focus group of potential users. What “buttons” would they push? What do they think will happen if they take a specific action? How is that different than what you had intended? Starting with usability will likely create changes to the design of the project. It is FAR less expensive to do that before the code has been written than after.

    One of the delightful things about writing code is that it can be like putting together a puzzle in which connecting one piece to another can cause the picture to mutate. There is an old programming joke based on the song, “99 Bottles of Beer on the Wall.” It goes, “99 bugs in the code, 99 bugs in the code, take one down, patch it around, 117 bugs in the code.”

    If you wait until the end to test, you might run out of time or money. Waiting until the end risks finding a catastrophic bug that has gotten very expensive to fix. Testing should occur concurrently with coding.

    Testing is a specialized skill. To thoroughly test a product, a QA tester will create a plan that systematically exercises each of the different parts of the code and the whole. They document the outcomes of those tests in a clear and technical manner, so that bugs can be reproduced by the programmers.

    The focus of testing is different than that of development. Development is trying to solve problems, QA is trying to find problems, and these are different mindsets. In some ways, QA testing is a bit like proofreading, and is most effective when someone different than the original programmer performs the tests. When a programmer tests their own code, it is very easy for people to miss or overlook errors because they are so familiar with the functions, they don’t even realize when they aren’t working properly.

    Testing saves development money and time over the life of the project. It may seem like it “costs” more in the short run, and it can be hard to measure the value of the problems you don’t have. But, to get a picture of the value of testing, go to the Google Play Store or the iTunes App Store and look at apps that have poor ratings and read the comments. What are people complaining about? Things not functioning right or as expected. Too many complaints about functioning, and your app will be removed from the stores.

    Iterations Keep You in the Loop

    Iterations Keep You in the Loop

    There are some developers who will do all the development prior to revealing the product to their client. This is a great way to get something other than what you had wanted and have little to no recourse to get it changed or avoid cost overruns.

    With iterations, you are never surprised by the product delivered to you.

    At Salty Dog Technology we use an iterative process.  The iterative process ensures that the client is getting the product they want and need.  

    An iteration is a block of work, usually encompassing a single function/feature or group of related functions/features.

    An example of a single iteration:

    • Describe the work to be done in detail in a Statement of Work. 
    • Get approval from the client.
    • Wireframe work to be done.
    • Get approval from the client.
    • Code the functions/features.
    • Demonstrate functioning of functions/features to the client
    • Deliver code written to client

    An iteration usually takes anywhere from 1 week to 1 month, depending on the turnaround time for questions and the amount of work to be done.  Iterations help you to minimize risk, as you are constantly getting to see/use/take possession of work done throughout the process.   

    Another advantage of iterations is that course corrections can be made early. … explain… … Work occurs on your schedule.

    For example: Imagine you want an app. You have imagined that your app has three core functions. With the iterative process each function may be an individual iteration.  After coding the first function, we realize that there are multiple possibilities for the way that users are directed to the second and third functions.  You get to use the app and we discuss which of those possibilities make the most sense for your app.  You chose one, and we code the next iteration.  The finished product contains the features the way you wanted them to appear based on your in-depth knowledge of the market for the product/use of the product.  

    Now imagine that you approached a developer who agreed to make the app for you but who doesn’t work iteratively or in partnership with you.  You tell them what you want the app to do.  They begin coding and when they face a decision point- they make it- you are never consulted.  You receive a completed app.  It might be what you wanted.  It might not.  You don’t know what you’ll get until the very end because you were forced to take a blind leap of faith that they would finish it appropriately.  

    We don’t ask you to walk off a cliff and hope there is a net below to catch you.

    We want you to feel confident that the product being built is what you want and need.  We want you to be the one to direct the project and make choices.  We want to set you and your product up for success.   

    So- when you hear us talking about iterations- this is what we mean.  It is one of the many ways that we keep you in charge and in the loop.  

    Minimum Viable Product- MVP

    Minimum Viable Product- MVP

    Minimum Viable Product (MVP) is a term frequently used, with an abundance of definitions, and is often poorly understood.

    An MVP isn’t an incomplete product, it is the the MINIMUM product that will accomplish what you desire.  It is a whole, useful, and useable product. (more…)

    Client-Centered Engagmenet

    Client-Centered Engagmenet

    We believe that responsible, client-centered engagement results in high-quality products that people are happy with.

    Client-centered engagement means that the client is at the center of and drives the process. It is a concept I borrowed from therapy, as I was a social worker in my previous career and it describes how we work at Salty Dog.

    Too often a conversation is just one person waiting until the other stops talking so that they can talk. At Salty Dog Technology, we work hard at listening and understanding. We want to hear your ideas and we want you to know that we see the project the same way that you do. Listening may take the form of a phone conversation, a face-to-face meeting, or an email. Whatever the format, for the duration of the conversation, you are the sole focus. We reflect back what we hear so that you have a chance to clarify your statements.

    Have you ever left a conversation where both people are saying the same thing, but later you find out that you both understood something different? Imagine that you and a friend agree to go see a movie. You’re thinking of something with lots of explosions but they’re planning to see a comedy. You don’t realize that you left the conversation with different expectations. We call this “false closure.”

    To avoid false closure we put together outlines, draw pictures of screens, and make mock ups to depict what we heard in the conversation with you. You have the chance to consider how you would like your screens to look and make adjustments before we begin coding. We are experts at design and programming, but that means little if the product isn’t what you had wanted.

    We check in with you a lot. If you call us and want to talk about your project, we will make the time to listen. Your communication isn’t getting in the way of the work, it is the work. It is the best interest of the project to keep you updated with progress reports. As each portion is finished, you will be able to see and interact with it. If we encounter an unexpected roadblock, we will contact you right away and discuss possible courses of action. We will never just surprise you with a bill and a solution we made up ourselves.

    Part of the Salty Dog process is to work in iterations- small chunks of work that result in the next piece of the product. Because we work iteratively, at the end of each cycle, you’ll have pages to look at and functionality to try out. You can verify it is working how you wanted and make any needed changes.

     

    You get the source code at the end of each cycle. You are the owner of your code, it gets in your hands at stage of the project. Your project shouldn’t be a mystery to you. We’ve all seen the disastrous results that can occur when a contractor doesn’t show or deliver the product until the very end, or worse, never delivers despite being paid. Salty Dog Technology believes that as you pay for the code, you own it and can access it.

    You are the first user that we test your product on. We want you to be happy with how it functions. We want you to see how your idea made manifest works. We will eventually test your product with other people to make sure that it is the best product it can be, but you are the first and most important tester.

    You could be reading this and be thinking that you don’t actually want to talk to us that often. That’s ok, too. We work for you, and take our cues from you.

    We want to build long-term relationships with our clients so that you will come back to Salty Dog the next time you have a project.

    We’re listening- what would you like to tell us?