5 ms·

As a developer turned sales and marketing person with a couple of products and a software company boy do I agree with this post. I have a friend that built and

As a developer turned sales and marketing person with a couple of products and a software company boy do I agree with this post. I have a friend that built and sold an online accounting app for £XX millions (yep, that's two x's there) a year or so ago. He originally created the app using classic ASP, as that was all he knew at the time. After a few years of growth they started to build a .Net version of the app but it never saw the light of day. Guess why? Because they were too busy growing the company and ultimately selling it. And this is exactly the right approach. I'm pretty sure with hindsight he wouldn't have bothered with the .Net version of the app. It's way too easy to get bogged down in using <latest trendy frameworks>, <trendiest latest NoSQL> or some other technical bullshit that doesn't actually add value for your customers. I know because I've done it and wasted far too many hours of precious development time. So now whenever I'm reviewing the list of cards in Trello for the next sprint on our app http://www.staffsquared.com http://www.staffsquared.com I ask myself two very simple questions: - Will this bug fix/change/new feature add new paying customers? - Will this bug fix/change/new feature reduce our customer attrition If it doesn't tick one of those two boxes, it doesn't go in.

mason55 12y ago
> - Will this bug fix/change/new feature add new paying customers? - Will this bug fix/change/new feature reduce our customer attrition Where do things like support and maintenance costs fit in? Developing internal tools to help with administration, spending time refactoring code to improve future maintenance abilities, investing in internal features that will increase scalablity, etc? That's where a lot of people get sucked into the "new technology" trap as it's tough to know the exact moment that you need to invest in non-customer facing infrastructure as an investment in the future. Twitter is fine now but back in 2010 they infamous for always being down; someone more reliable very easily could have come in and ate their lunch.
- simonswords82 12y ago
  I make you right about Twitter. I think my primary point, and what I read in the OPs article is this...don't let the fear and worry about the tech you're using take your eye off the customers paying your bills. I'd much rather have millions of customers using my app while I work out how to fix technical debt issues, than piss about with my choice of tech for 6 months while the competition takes money off of the table. I love technology, but too often it's a distraction in business. Twitter will have known they pushed their luck on reliability while they scaled, and seemingly got the balance right as it didn't take them down. If you're interested, here's some more specific answers to the points you raised: So keep in mind we usually have a couple of engineers assigned to the backlog for Staff Squared. Their time is precious, but as with all things a technical solution is not always necessary, so we will often use workarounds: Internal tools: They exist to help the sales team onboard more customers, or help the support team keep our customers happy, or keep the management team in the loop and so on. Most of these things can be traced back to my two points (getting/keeping customers) and if they can't then they're nice to haves and can wait. Alternatively we'll ask a non-techie member of the team to run a process manually using what they've already got available. We only create a tool if the process we're experimenting with actually delivers enough value to warrant the coding time to automate it. Internal features that increase scalability. These do go in to the backlog, and they're things like integrating S2 with our CRM, or setting up KPIs (e.g http://imgur.com/itFzSaO http://imgur.com/itFzSaO) and dashboards for important info. Again, most of these things can be traced back to gaining more customers because we use the data to refine our onboarding and overall user experience, or speaking with customers who aren't as engaged with the app as we would like and ensuring they stay a customer. Technical debt due to a lack of foresight in code maintenance is not something you want if you can help it. Having said that, I can't think of a bigger technical debt than complex, mature accounting app written in classic ASP running stored procedures to pull data from complex SQL views. So while we do of course have to factor in to sprints things like performance enhancements, code refactors, or just plain old upgrades to the version of .Net MVC we're using, they're just not as much of a priority as my two main justifications for the cards I include in upcoming sprints (Getting customers/keeping customers).
  - nstart 12y ago
    Agreed with the interpretation of the OP's article and agree with the general sentiment of building something that's perfect on the backend while ignoring the need to get customers is just wrong. That said, for anyone reading this, only a sith deals in absolutes and I'd like to share my experience of working with two companies that thought it was fine for tech to take a back seat and for customers to be the driving point. The first company was an erp company. They still run on fox pro. Yes. Fox pro. They've built a relatively feature stable foundation which they can keep selling to customers. Great right? Customers clearly don't care about the tech running in the background. If you are in there just for the money that works I guess. And that was the problem of customers over tech approach. The UIs were shoddy. There were bugs. The UX ended up making users go through frustrating processes to complete tasks. Report generation was slow. There was a mountain or two of technical debt in the code base that had no tests. And while the money kept rolling in, it felt wrong to keep pushing the product when it wasn't something we ourselves couldn't fall in love with. The second example is an ecommerce company that I worked at that kept pushing ahead with feature after feature on one tight deadline to a tighter deadline right after. The result was a system that eventually started seeing >10 second load times. We also had a process where customers would come and pay us offline (online payments are still in early days where I am) and the system would slow down heavily during peak hours. But again, the customers were coming so my personal feelings on long load times and long wait times was just nonsense right? Again. Money or love? Which comes first? At this point I need to say that my personal choice is love first. If making money means I have to sacrifice the love for the experience I'd rather not do it at all. This is just the other side of the coin of going (IMO) deep into the mantra of 'customers don't care about tech'. Ultimately this is just my opinion. I thought it would be worth sharing. Cheers :)
jnbiche 12y ago
>- Will this bug fix/change/new feature add new paying customers? >- Will this bug fix/change/new feature reduce our customer attrition > If it doesn't tick one of those two boxes, it doesn't go in. What about security fixes? Or secure coding practices? How do those fit in? That aside, the attitude above seems like a good way to quickly get deep into technical debt.
- lmm 12y ago
  > What about security fixes? Or secure coding practices? How do those fit in? I suspect that, sad as it is, a profit-making business probably shouldn't spend much effort on those - the financial cost/benefit is pretty poor. Customers are overwhelmingly indifferent to being hacked.
  - simonswords82 12y ago
    Well our customers might be but I'm definitely not. Even a sniff of a security issue would be enough for us to drop everything and work to get it investigated. A loss in customer faith for a brand or product is a tough thing to restore.
- simonswords82 12y ago
  Hopefully I've explained enough about my approach to technical debt in my response above. I think the problem of not being able to pay the bills due to a lack of customers is much more difficult to overcome than any issues caused by technical debt. More customers usually means more money which buys you time.
slowmovintarget 12y ago
While I agree with the content, this is another one of those misleading titles. As the author comes to reveal over the course of his post, the technology absolutely matters. Using a technology because it is cool and not because it is the best fit for the problem will lead to failure as surely as using the wrong material in a construction project will cause a build-out to fail. The other point he makes is use what you know, or get people who have the necessary knowledge. Knowledge matters more than technology, but technology matters.

mason55 12y ago

> - Will this bug fix/change/new feature add new paying customers? - Will this bug fix/change/new feature reduce our customer attrition Where do things like support and maintenance costs fit in? Developing internal tools to help with administration, spending time refactoring code to improve future maintenance abilities, investing in internal features that will increase scalablity, etc? That's where a lot of people get sucked into the "new technology" trap as it's tough to know the exact moment that you need to invest in non-customer facing infrastructure as an investment in the future. Twitter is fine now but back in 2010 they infamous for always being down; someone more reliable very easily could have come in and ate their lunch.

simonswords82 12y ago
I make you right about Twitter. I think my primary point, and what I read in the OPs article is this...don't let the fear and worry about the tech you're using take your eye off the customers paying your bills. I'd much rather have millions of customers using my app while I work out how to fix technical debt issues, than piss about with my choice of tech for 6 months while the competition takes money off of the table. I love technology, but too often it's a distraction in business. Twitter will have known they pushed their luck on reliability while they scaled, and seemingly got the balance right as it didn't take them down. If you're interested, here's some more specific answers to the points you raised: So keep in mind we usually have a couple of engineers assigned to the backlog for Staff Squared. Their time is precious, but as with all things a technical solution is not always necessary, so we will often use workarounds: Internal tools: They exist to help the sales team onboard more customers, or help the support team keep our customers happy, or keep the management team in the loop and so on. Most of these things can be traced back to my two points (getting/keeping customers) and if they can't then they're nice to haves and can wait. Alternatively we'll ask a non-techie member of the team to run a process manually using what they've already got available. We only create a tool if the process we're experimenting with actually delivers enough value to warrant the coding time to automate it. Internal features that increase scalability. These do go in to the backlog, and they're things like integrating S2 with our CRM, or setting up KPIs (e.g http://imgur.com/itFzSaO http://imgur.com/itFzSaO) and dashboards for important info. Again, most of these things can be traced back to gaining more customers because we use the data to refine our onboarding and overall user experience, or speaking with customers who aren't as engaged with the app as we would like and ensuring they stay a customer. Technical debt due to a lack of foresight in code maintenance is not something you want if you can help it. Having said that, I can't think of a bigger technical debt than complex, mature accounting app written in classic ASP running stored procedures to pull data from complex SQL views. So while we do of course have to factor in to sprints things like performance enhancements, code refactors, or just plain old upgrades to the version of .Net MVC we're using, they're just not as much of a priority as my two main justifications for the cards I include in upcoming sprints (Getting customers/keeping customers).
- nstart 12y ago
  Agreed with the interpretation of the OP's article and agree with the general sentiment of building something that's perfect on the backend while ignoring the need to get customers is just wrong. That said, for anyone reading this, only a sith deals in absolutes and I'd like to share my experience of working with two companies that thought it was fine for tech to take a back seat and for customers to be the driving point. The first company was an erp company. They still run on fox pro. Yes. Fox pro. They've built a relatively feature stable foundation which they can keep selling to customers. Great right? Customers clearly don't care about the tech running in the background. If you are in there just for the money that works I guess. And that was the problem of customers over tech approach. The UIs were shoddy. There were bugs. The UX ended up making users go through frustrating processes to complete tasks. Report generation was slow. There was a mountain or two of technical debt in the code base that had no tests. And while the money kept rolling in, it felt wrong to keep pushing the product when it wasn't something we ourselves couldn't fall in love with. The second example is an ecommerce company that I worked at that kept pushing ahead with feature after feature on one tight deadline to a tighter deadline right after. The result was a system that eventually started seeing >10 second load times. We also had a process where customers would come and pay us offline (online payments are still in early days where I am) and the system would slow down heavily during peak hours. But again, the customers were coming so my personal feelings on long load times and long wait times was just nonsense right? Again. Money or love? Which comes first? At this point I need to say that my personal choice is love first. If making money means I have to sacrifice the love for the experience I'd rather not do it at all. This is just the other side of the coin of going (IMO) deep into the mantra of 'customers don't care about tech'. Ultimately this is just my opinion. I thought it would be worth sharing. Cheers :)

jnbiche 12y ago

>- Will this bug fix/change/new feature add new paying customers? >- Will this bug fix/change/new feature reduce our customer attrition > If it doesn't tick one of those two boxes, it doesn't go in. What about security fixes? Or secure coding practices? How do those fit in? That aside, the attitude above seems like a good way to quickly get deep into technical debt.

lmm 12y ago
> What about security fixes? Or secure coding practices? How do those fit in? I suspect that, sad as it is, a profit-making business probably shouldn't spend much effort on those - the financial cost/benefit is pretty poor. Customers are overwhelmingly indifferent to being hacked.
- simonswords82 12y ago
  Well our customers might be but I'm definitely not. Even a sniff of a security issue would be enough for us to drop everything and work to get it investigated. A loss in customer faith for a brand or product is a tough thing to restore.
simonswords82 12y ago
Hopefully I've explained enough about my approach to technical debt in my response above. I think the problem of not being able to pay the bills due to a lack of customers is much more difficult to overcome than any issues caused by technical debt. More customers usually means more money which buys you time.

slowmovintarget 12y ago

While I agree with the content, this is another one of those misleading titles. As the author comes to reveal over the course of his post, the technology absolutely matters. Using a technology because it is cool and not because it is the best fit for the problem will lead to failure as surely as using the wrong material in a construction project will cause a build-out to fail. The other point he makes is use what you know, or get people who have the necessary knowledge. Knowledge matters more than technology, but technology matters.