5 ms·

> will address the needs of the community that it Serves How do you know that it does address their needs and how do you know that they care? > It's a free ap

by anamax 5y ago

> will address the needs of the community that it Serves How do you know that it does address their needs and how do you know that they care? > It's a free app, for a non-profit). And what makes doing it worth two years of your life?

ChrisMarshallNY 5y ago
Like I said, it doesn’t win me fans, in this community. > How do you know that it does address their needs and how do you know that they care? Let’s just say that I know the target demographic fairly well, having been a member of it for over 40 years, and having written a major, worldwide, infrastructure for it (over a period of ten years -also, on a volunteer basis). I eat my own dog food. I use the software I’ve written, pretty much daily, along with thousands of others, worldwide. In fact, this app uses that infrastructure, and integrates it with a simple social graph, so you could say the app is actually the result of over a dozen years of work. Also, the development process I use is highly testable. TestFlight[0] is, for all intents and purposes, a “mini App Store.” The app is a full-fat release, and is constantly being vetted by Apple. It’s not some crappy lash-up, like so many MVPs. It’s quite amazing, that it has been used constantly, since one month after I started coding. I can write a lot of really good code, really quickly. What I released to TestFlight, in October 2020, could have easily been considered “The heck with it, let’s ship” by many corporations. Even six months later, when we originally thought we had our first “shippable” app, it was still pretty pathetic. What we have now, is something we are all quite happy with. We still have some months of testing and preparation to go, before we have our first public beta. Brand damage is something that many geeks don’t understand, but is absolutely devastating, and almost impossible to repair. Even if there are some initial stumbles and hiccups (almost guaranteed), it won’t be an E.L.E. for the project or the team, and it won’t destroy our credibility. Even if it’s a complete flop (which it won’t be -I guarantee), people will still take our team seriously, so we will still be able to keep trying. I fully expect it to take several months (or longer) to mature, after we release it, but it is designed to be “infrastructure-level,” daily use, software. Good things take time. We have no problem with a “slow burn.” Also, the software that I write Serves a fairly sensitive demographic. Security, Privacy, and Accessibility are of paramount importance. Failure in these areas could have severe and detrimental impact on people’s lives. It’s not hyperbole, at all, to say people’s lives depend on the Quality of my work. I can’t afford to “move fast and break things,” as said “things” could be people’s lives. There’s a reason that I’ve repeated “people’s lives,” so often, above. I think it needs to be driven home. > And what makes doing it worth two years of your life? Two years is nothing (see 40 years, and 10 years, above). I’ve written software, professionally, and personally, that has lasted decades. I’m fairly adept at playing the long game (not particularly valued, in today’s tech industry). Also, the software that I have written personally, has the potential to make a major impact on people’s lives. It’s pretty important stuff; not some “leisure/entertainment” app for bored yuppies. I take my job pretty seriously. Some things are worth that kind of effort. If I had to explain, you wouldn’t understand. [0] https://developer.apple.com/testflight/ https://developer.apple.com/testflight/
- gcollard- 5y ago
  Parent is working on scheduling tools for NA meetings. Yes some things are important and can’t be broken without some serious real world consequences. MVP is “the first thing that stick”. The method to get there should be meticulously engineered to cut as much iteration time between prototypes as possible. When your ugly prototype shows strong traction by its own and test users are asking you to keep the prototype then you know you have a rough diamond to cut. Obviously when you have a sizeable user base, know the market very well and your market isn’t that much competitive you are at an advantage. Beware of market expertise ego and dogfooding as it only reinforce your expertise and biases. Bring industry newcomers to your project for feedback, it’s the only way to make sure your expertise doesn’t make your product only valuable for yourself.
  - ChrisMarshallNY 5y ago
    > Beware of market expertise ego and dogfooding as it only reinforce your expertise and biases. Bring industry newcomers to your project for feedback, it’s the only way to make sure your expertise doesn’t make your product only valuable for yourself. Good point, but this particular demographic has no problem letting me know where the rough bits are. The thing about the MVP pattern, is that software people seem to think that we get to go by different rules, from everyone else. Software lets us iterate quickly, and I have found ways to leverage that (I call it "Evolutionary Design"[0]), but that does not give me license to deliberately foist garbage onto end users; especially ones that are quick to anger, and slow to forgive. Every other craft, engineering discipline, and production system, throughout history, has had to take the risk of going through a design phase, based on expertise, user surveys, need evaluations, etc., then actually get to at least production prototype phase, before determining whether or not to proceed further. It's a risk, but one that everyone has been taking, for hundreds of years. For some reason, we software people seem to think that the flexibility of software absolves us of the Responsibility to deliver a high-quality prototype, and that we don't need to take the same risks that everyone else has been taking throughout history. I totally agree that said flexibility gives us a great opportunity to actually deliver a much more suitable product, than was achievable, with other production methodologies, and ease of iteration is how we get there. I just don't agree that we start by throwing out some junk, without first doing some real homework. I'm really tired of seeing junk prototypes becoming the shipped product. Once it is out there, and running in production, it's quite difficult to make the kinds of pivots and changes that are almost certainly required, without turning the app into a disgusting mess. One of the nice things about the last couple of years, is that I have been able to completely nuke the database, several times, as we have pivoted. I'd never be able to do that, if it were a production app. I'd have to devise some kind of horrible kludge, or, more likely, limit the pivot. [0] https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-...

by anamax 5y ago

ChrisMarshallNY 5y ago

Like I said, it doesn’t win me fans, in this community. > How do you know that it does address their needs and how do you know that they care? Let’s just say that I know the target demographic fairly well, having been a member of it for over 40 years, and having written a major, worldwide, infrastructure for it (over a period of ten years -also, on a volunteer basis). I eat my own dog food. I use the software I’ve written, pretty much daily, along with thousands of others, worldwide. In fact, this app uses that infrastructure, and integrates it with a simple social graph, so you could say the app is actually the result of over a dozen years of work. Also, the development process I use is highly testable. TestFlight[0] is, for all intents and purposes, a “mini App Store.” The app is a full-fat release, and is constantly being vetted by Apple. It’s not some crappy lash-up, like so many MVPs. It’s quite amazing, that it has been used constantly, since one month after I started coding. I can write a lot of really good code, really quickly. What I released to TestFlight, in October 2020, could have easily been considered “The heck with it, let’s ship” by many corporations. Even six months later, when we originally thought we had our first “shippable” app, it was still pretty pathetic. What we have now, is something we are all quite happy with. We still have some months of testing and preparation to go, before we have our first public beta. Brand damage is something that many geeks don’t understand, but is absolutely devastating, and almost impossible to repair. Even if there are some initial stumbles and hiccups (almost guaranteed), it won’t be an E.L.E. for the project or the team, and it won’t destroy our credibility. Even if it’s a complete flop (which it won’t be -I guarantee), people will still take our team seriously, so we will still be able to keep trying. I fully expect it to take several months (or longer) to mature, after we release it, but it is designed to be “infrastructure-level,” daily use, software. Good things take time. We have no problem with a “slow burn.” Also, the software that I write Serves a fairly sensitive demographic. Security, Privacy, and Accessibility are of paramount importance. Failure in these areas could have severe and detrimental impact on people’s lives. It’s not hyperbole, at all, to say people’s lives depend on the Quality of my work. I can’t afford to “move fast and break things,” as said “things” could be people’s lives. There’s a reason that I’ve repeated “people’s lives,” so often, above. I think it needs to be driven home. > And what makes doing it worth two years of your life? Two years is nothing (see 40 years, and 10 years, above). I’ve written software, professionally, and personally, that has lasted decades. I’m fairly adept at playing the long game (not particularly valued, in today’s tech industry). Also, the software that I have written personally, has the potential to make a major impact on people’s lives. It’s pretty important stuff; not some “leisure/entertainment” app for bored yuppies. I take my job pretty seriously. Some things are worth that kind of effort. If I had to explain, you wouldn’t understand. [0] https://developer.apple.com/testflight/ https://developer.apple.com/testflight/

gcollard- 5y ago
Parent is working on scheduling tools for NA meetings. Yes some things are important and can’t be broken without some serious real world consequences. MVP is “the first thing that stick”. The method to get there should be meticulously engineered to cut as much iteration time between prototypes as possible. When your ugly prototype shows strong traction by its own and test users are asking you to keep the prototype then you know you have a rough diamond to cut. Obviously when you have a sizeable user base, know the market very well and your market isn’t that much competitive you are at an advantage. Beware of market expertise ego and dogfooding as it only reinforce your expertise and biases. Bring industry newcomers to your project for feedback, it’s the only way to make sure your expertise doesn’t make your product only valuable for yourself.
- ChrisMarshallNY 5y ago
  > Beware of market expertise ego and dogfooding as it only reinforce your expertise and biases. Bring industry newcomers to your project for feedback, it’s the only way to make sure your expertise doesn’t make your product only valuable for yourself. Good point, but this particular demographic has no problem letting me know where the rough bits are. The thing about the MVP pattern, is that software people seem to think that we get to go by different rules, from everyone else. Software lets us iterate quickly, and I have found ways to leverage that (I call it "Evolutionary Design"[0]), but that does not give me license to deliberately foist garbage onto end users; especially ones that are quick to anger, and slow to forgive. Every other craft, engineering discipline, and production system, throughout history, has had to take the risk of going through a design phase, based on expertise, user surveys, need evaluations, etc., then actually get to at least production prototype phase, before determining whether or not to proceed further. It's a risk, but one that everyone has been taking, for hundreds of years. For some reason, we software people seem to think that the flexibility of software absolves us of the Responsibility to deliver a high-quality prototype, and that we don't need to take the same risks that everyone else has been taking throughout history. I totally agree that said flexibility gives us a great opportunity to actually deliver a much more suitable product, than was achievable, with other production methodologies, and ease of iteration is how we get there. I just don't agree that we start by throwing out some junk, without first doing some real homework. I'm really tired of seeing junk prototypes becoming the shipped product. Once it is out there, and running in production, it's quite difficult to make the kinds of pivots and changes that are almost certainly required, without turning the app into a disgusting mess. One of the nice things about the last couple of years, is that I have been able to completely nuke the database, several times, as we have pivoted. I'd never be able to do that, if it were a production app. I'd have to devise some kind of horrible kludge, or, more likely, limit the pivot. [0] https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-...