{"id":564,"date":"2015-10-22T22:57:19","date_gmt":"2015-10-23T05:57:19","guid":{"rendered":"http:\/\/marcusvorwaller.com\/blog\/?p=564"},"modified":"2016-05-12T02:22:19","modified_gmt":"2016-05-12T09:22:19","slug":"breadth-after-depth-dont-set-yourself-up-to-fail-in-software-projects","status":"publish","type":"post","link":"https:\/\/marcusvorwaller.com\/blog\/2015\/10\/22\/breadth-after-depth-dont-set-yourself-up-to-fail-in-software-projects\/","title":{"rendered":"Breadth after Depth: Don’t Set Yourself Up to Fail in Software Projects"},"content":{"rendered":"

It is very easy for software product owners to be lured into the trap of designing software to solve a broad problem for many people right from the start. <\/span>This is a mistake.<\/b> Most ideas start to scratch an itch or build something that is unique to a particular company or group. Then as you think more about solving it, the natural tendency is to go bigger and think “hey, this could also solve these similar problems!” You increase the scope of your project to encompass those problems as well. After all, it’s software, there’s no cost to make your product just a bit more generalized, right?<\/span><\/p>\n

No. Again, this\u00a0is a mistake.<\/strong><\/p>\n

Build to solve the smaller problem<\/span><\/i>. Learn the domain by focusing on solving the problem you started off with from A to Z. Once you have done that, expand to similar problems or refactor your software to a higher level of abstraction.<\/span><\/p>\n

For example, say you rent a house and find it tough to communicate with your landlord. You decide you want to build software to help landlords communicate with their tenants. Great. As you start thinking about it you realize that you could also solve the problem for people who rent out their houses to vacationers for the summer or for commercial apartment building landlords to communicate with many tenants in a building. After all, they’re basically the same problem, right?<\/span><\/p>\n

No.<\/p>\n

They require different models, different abstractions and different user interfaces. <\/span>Solving everyone\u2019s problem means solving no one\u2019s problem.<\/b> Instead it means getting bogged down in creating software generic enough to not exclude any potential customers. It may seem like you’re making big fancy plans and building elegant software models when in reality you are severely lengthening your time to market and setting yourself up to build a product that doesn’t fully solve any one of your potential customer’s problems.<\/span><\/p>\n

Here\u2019s what not to do:<\/span><\/p>\n