4 ms·

So I've seen both sides of the "unpopularity" issue. On the one hand, the other comments about pushing too fast for new features are valid. On the other hand,

So I've seen both sides of the "unpopularity" issue. On the one hand, the other comments about pushing too fast for new features are valid. On the other hand, it very much depends on the developer in question. I'd say roughly 50% of the devs who claim to be in your category are, in fact, wasting dev cycles on pedantic things that have no impact on the end user. As an example, I had one developer take 6 months to build a (relatively simple) top nav for a web app. This shouldn't have taken more than 1-2 weeks, even with a careful eye for detail.

ChrisMarshallNY 5y ago
> I had one developer take 6 months to build a (relatively simple) top nav for a web app. This shouldn't have taken more than 1-2 weeks, even with a careful eye for detail. Oh, you mean "bikeshedding." Here's an example of the difference between basic quality, and High Quality: If you look at most of the repos for SPM modules in my portfolio[0], you'll see that the vast majority have test harnesses. I prefer using test harnesses[1]. These test harnesses tend to be pretty damn robust apps. Many are "ready for app store" robust. A lot of folks would just publish them, "as is." I've been writing apps for a very long time. I'm pretty good at this. I can write a fairly decent test harness, with full app capabilities, in less than a day. If I take the time to localize it, maybe add a day or so. Here's an example of some test harnesses[2]. Note that there are four of them. These represent the four different target environments for Apple (iOS/iPadOS, WatchOS, TVOS, and MacOS). I'll probably need to fork iOS and iPadOS, in the future, but we're not there, yet. A single codebase is still good for both (But I hope that SwiftUI makes supporting multiple platforms easier. We'll see...). They test a Bluetooth framework[3]. It probably took me around a week or so, to write each one. They are pretty damn good. I deliberately went "over the top," with them, because I like to exemplify what I consider halfway decent Quality coding practices. I think they are all "App Store ready." I decided to actually go ahead, and create a set of apps, based on these[4], [5], [6]. Here's the codebase for those apps[7]. I spent well over a month, on each, after merging over the test harness codebases, to make them ready for the App Store. Lots of UX testing, removing code that only applied to testing, and adding "friendlier" user interface. I didn't do much "eye candy," like animations. If I did that, then I probably would have spent another month on each. Animations tend to bring ... interesting ... bugs. I'm going through that, right now, with the app currently under development. I'm working on an app that I started about a year ago. Actually, I started it over ten years ago, if you include the two servers that I wrote, upon which it depends. One of the reasons that it has taken so long, is that I have truncated months of work, and tossed them in the garbage, because they were not the proper way to go. I have an "evolutionary design" process[8], that means this can happen. I plan for it. I've probably shitcanned three months' of work. Another thing that I do, is have an "always beta" approach to Quality. I maintain the product at "incomplete, but ship Quality" status for as much of the project as possible. In fact, I've been sharing it with the team, using TestFlight External Testing, since Oct 3, 2020 at 7:47 AM (I got that from the TestFlight metadata). The initial Git checkin of the project was Sept. 4. That means that the app has been stable and robust enough for user testing, and approval for basic App Store release (TestFlight External Testing is a more relaxed standard, but try pushing out a crasher, and see how far that goes). I add localization support, accessibility, Dark Mode support, leak testing, etc., at every turn. It's very useful, because I can solicit immediate feedback from non-tech team members. It also means that the "basics" for App Store release are constantly being tested and validated. Even more useful, if we want to ask for money, it's dam easy. We just loop the person we're begging from, into the TestFlight External Tester pool, and they can run the app without a Marketing chaperone, or sacrifices to the demo gods. We can also get valuable feedback from them. It's really, really nice, and it has been, for many months. I feel like we are now at a "starting point." Even though it has been a fully-functioning, release-ready app for the last couple of months, it still needs the "MVP treatment," where the testing pool is expanded, and we start applying it to "in the wild" scenarios. We've kept it to a small user pool, so far. Lots of companies use their customers as guinea pigs for the first several releases; usually by shoving baling-wire-and-duct-tape junk down their throats (and making them pay for it), before hitting their stride. It's a deliberate strategy. Some months ago, I read a post, here, by a founder, declaring that "if you don't get physically sick at the quality of the code in your MVP, then you are spending too much time on code quality." Basically, deliberately write garbage, and force it on your users. This has the very significant disadvantage of establishing a foundation of sand. Everyone always plans to "go back and do it right," but that never actually happens. That "physically sickening" MVP is the product for life. One of the reasons that I took on this project, was the founder is a friend of mine. He is running it as an NPO (501c3), and putting his own money into it. He doesn't really have much of it, to begin with. Also, more alarmingly, he didn't actually have a particularly good idea of what, exactly, he wanted the app to be. That's a recipe for disaster. He asked me to help him vet some development shops he was approaching, to realize his vision. It was eye-opening. He got a number of ridiculous quotes. I know what is necessary for this type of project (not small). For example, when one said that they'll deliver a full multi-server, multi-client app for MVP in three months (firm), upon getting a vague, hand-wavy requirements spec, it was hard for me to keep a straight face. The most honest one, was one that quoted a valid price (six figures, and minimum six months), then basically said "come back when you know what you want." I respected that one. After a few of these, I just got disgusted, and said "Screw this. I'll do it." I've been developing it for free, as a native iOS/iPadOS app. We have refined the specification and mission, as the app has progressed. Having a high-quality, ship-ready prototype, goes a long way towards developing a good app. He has to pinch himself. [0] https://stackoverflow.com/story/chrismarshall https://stackoverflow.com/story/chrismarshall [1] https://littlegreenviper.com/miscellany/testing-harness-vs-unit/ https://littlegreenviper.com/miscellany/testing-harness-vs-u... [2] https://github.com/RiftValleySoftware/RVS_BlueThoth/tree/master/Tests https://github.com/RiftValleySoftware/RVS_BlueThoth/tree/mas... [3] https://github.com/RiftValleySoftware/RVS_BlueThoth https://github.com/RiftValleySoftware/RVS_BlueThoth [4] https://apps.apple.com/us/app/blue-van-clef-for-mobile/id1511428132 https://apps.apple.com/us/app/blue-van-clef-for-mobile/id151... (iOS -Includes Watch app) [5] https://apps.apple.com/us/app/blue-van-clef/id1529005127 https://apps.apple.com/us/app/blue-van-clef/id1529005127 (Mac) [6] https://apps.apple.com/us/app/blue-van-clef-for-tv/id1529181618 https://apps.apple.com/us/app/blue-van-clef-for-tv/id1529181... (TV) [7] https://github.com/RiftValleySoftware/BlueVanClef https://github.com/RiftValleySoftware/BlueVanClef [8] https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-...
- lytefm 5y ago
  > "if you don't get physically sick at the quality of the code in your MVP, then you are spending too much time on code quality." While exaggerated, I'd definitely agree. If you don't quite know yet where exactly your company will pivot to in the next year or whether the company will still exist, it doesn't make sense to optimize for code quality - but for product-market fit instead. > Everyone always plans to "go back and do it right," but that never actually happens. That "physically sickening" MVP is the product for life. After having raised an 8 M Series A and hiring some more developers and UX experts, we're currently rewriting most of our app code. It's not an automatism that the bad code gets built on for eternity.
  - ChrisMarshallNY 5y ago
    Or you could hire people who do it right, the first time. Take a look at my work. Feel free to browse the commit logs, and see how fast I write it. I "put it all out there." It's quite possible to do very high-quality work, in very little time. Just maybe not from folks just out of code bootcamp. And...just to make it clear. I'm not looking for work. My dance card is very full, with the work I'm doing for free.
gilbetron 5y ago
I've developed different red flags over the decades, and while I don't doubt you've encountered developers that are really slow, one of my red flags is the time estimate of "1-2 weeks". That's the off-the-cuff estimate that people give when they have no idea how long something will take. "A week or two" is "I can't imagine it would take very long, but my imagination isn't very good" ;)
- ChrisMarshallNY 5y ago
  A classic: https://www.youtube.com/watch?v=qLcjUmBncZ8 https://www.youtube.com/watch?v=qLcjUmBncZ8
- drdec 5y ago
  Before it became a video game, Fortnight was a popular facetious codename for projects at my employer.

ChrisMarshallNY 5y ago

> I had one developer take 6 months to build a (relatively simple) top nav for a web app. This shouldn't have taken more than 1-2 weeks, even with a careful eye for detail. Oh, you mean "bikeshedding." Here's an example of the difference between basic quality, and High Quality: If you look at most of the repos for SPM modules in my portfolio[0], you'll see that the vast majority have test harnesses. I prefer using test harnesses[1]. These test harnesses tend to be pretty damn robust apps. Many are "ready for app store" robust. A lot of folks would just publish them, "as is." I've been writing apps for a very long time. I'm pretty good at this. I can write a fairly decent test harness, with full app capabilities, in less than a day. If I take the time to localize it, maybe add a day or so. Here's an example of some test harnesses[2]. Note that there are four of them. These represent the four different target environments for Apple (iOS/iPadOS, WatchOS, TVOS, and MacOS). I'll probably need to fork iOS and iPadOS, in the future, but we're not there, yet. A single codebase is still good for both (But I hope that SwiftUI makes supporting multiple platforms easier. We'll see...). They test a Bluetooth framework[3]. It probably took me around a week or so, to write each one. They are pretty damn good. I deliberately went "over the top," with them, because I like to exemplify what I consider halfway decent Quality coding practices. I think they are all "App Store ready." I decided to actually go ahead, and create a set of apps, based on these[4], [5], [6]. Here's the codebase for those apps[7]. I spent well over a month, on each, after merging over the test harness codebases, to make them ready for the App Store. Lots of UX testing, removing code that only applied to testing, and adding "friendlier" user interface. I didn't do much "eye candy," like animations. If I did that, then I probably would have spent another month on each. Animations tend to bring ... interesting ... bugs. I'm going through that, right now, with the app currently under development. I'm working on an app that I started about a year ago. Actually, I started it over ten years ago, if you include the two servers that I wrote, upon which it depends. One of the reasons that it has taken so long, is that I have truncated months of work, and tossed them in the garbage, because they were not the proper way to go. I have an "evolutionary design" process[8], that means this can happen. I plan for it. I've probably shitcanned three months' of work. Another thing that I do, is have an "always beta" approach to Quality. I maintain the product at "incomplete, but ship Quality" status for as much of the project as possible. In fact, I've been sharing it with the team, using TestFlight External Testing, since Oct 3, 2020 at 7:47 AM (I got that from the TestFlight metadata). The initial Git checkin of the project was Sept. 4. That means that the app has been stable and robust enough for user testing, and approval for basic App Store release (TestFlight External Testing is a more relaxed standard, but try pushing out a crasher, and see how far that goes). I add localization support, accessibility, Dark Mode support, leak testing, etc., at every turn. It's very useful, because I can solicit immediate feedback from non-tech team members. It also means that the "basics" for App Store release are constantly being tested and validated. Even more useful, if we want to ask for money, it's dam easy. We just loop the person we're begging from, into the TestFlight External Tester pool, and they can run the app without a Marketing chaperone, or sacrifices to the demo gods. We can also get valuable feedback from them. It's really, really nice, and it has been, for many months. I feel like we are now at a "starting point." Even though it has been a fully-functioning, release-ready app for the last couple of months, it still needs the "MVP treatment," where the testing pool is expanded, and we start applying it to "in the wild" scenarios. We've kept it to a small user pool, so far. Lots of companies use their customers as guinea pigs for the first several releases; usually by shoving baling-wire-and-duct-tape junk down their throats (and making them pay for it), before hitting their stride. It's a deliberate strategy. Some months ago, I read a post, here, by a founder, declaring that "if you don't get physically sick at the quality of the code in your MVP, then you are spending too much time on code quality." Basically, deliberately write garbage, and force it on your users. This has the very significant disadvantage of establishing a foundation of sand. Everyone always plans to "go back and do it right," but that never actually happens. That "physically sickening" MVP is the product for life. One of the reasons that I took on this project, was the founder is a friend of mine. He is running it as an NPO (501c3), and putting his own money into it. He doesn't really have much of it, to begin with. Also, more alarmingly, he didn't actually have a particularly good idea of what, exactly, he wanted the app to be. That's a recipe for disaster. He asked me to help him vet some development shops he was approaching, to realize his vision. It was eye-opening. He got a number of ridiculous quotes. I know what is necessary for this type of project (not small). For example, when one said that they'll deliver a full multi-server, multi-client app for MVP in three months (firm), upon getting a vague, hand-wavy requirements spec, it was hard for me to keep a straight face. The most honest one, was one that quoted a valid price (six figures, and minimum six months), then basically said "come back when you know what you want." I respected that one. After a few of these, I just got disgusted, and said "Screw this. I'll do it." I've been developing it for free, as a native iOS/iPadOS app. We have refined the specification and mission, as the app has progressed. Having a high-quality, ship-ready prototype, goes a long way towards developing a good app. He has to pinch himself. [0] https://stackoverflow.com/story/chrismarshall https://stackoverflow.com/story/chrismarshall [1] https://littlegreenviper.com/miscellany/testing-harness-vs-unit/ https://littlegreenviper.com/miscellany/testing-harness-vs-u... [2] https://github.com/RiftValleySoftware/RVS_BlueThoth/tree/master/Tests https://github.com/RiftValleySoftware/RVS_BlueThoth/tree/mas... [3] https://github.com/RiftValleySoftware/RVS_BlueThoth https://github.com/RiftValleySoftware/RVS_BlueThoth [4] https://apps.apple.com/us/app/blue-van-clef-for-mobile/id1511428132 https://apps.apple.com/us/app/blue-van-clef-for-mobile/id151... (iOS -Includes Watch app) [5] https://apps.apple.com/us/app/blue-van-clef/id1529005127 https://apps.apple.com/us/app/blue-van-clef/id1529005127 (Mac) [6] https://apps.apple.com/us/app/blue-van-clef-for-tv/id1529181618 https://apps.apple.com/us/app/blue-van-clef-for-tv/id1529181... (TV) [7] https://github.com/RiftValleySoftware/BlueVanClef https://github.com/RiftValleySoftware/BlueVanClef [8] https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-...

lytefm 5y ago
> "if you don't get physically sick at the quality of the code in your MVP, then you are spending too much time on code quality." While exaggerated, I'd definitely agree. If you don't quite know yet where exactly your company will pivot to in the next year or whether the company will still exist, it doesn't make sense to optimize for code quality - but for product-market fit instead. > Everyone always plans to "go back and do it right," but that never actually happens. That "physically sickening" MVP is the product for life. After having raised an 8 M Series A and hiring some more developers and UX experts, we're currently rewriting most of our app code. It's not an automatism that the bad code gets built on for eternity.
- ChrisMarshallNY 5y ago
  Or you could hire people who do it right, the first time. Take a look at my work. Feel free to browse the commit logs, and see how fast I write it. I "put it all out there." It's quite possible to do very high-quality work, in very little time. Just maybe not from folks just out of code bootcamp. And...just to make it clear. I'm not looking for work. My dance card is very full, with the work I'm doing for free.

gilbetron 5y ago

I've developed different red flags over the decades, and while I don't doubt you've encountered developers that are really slow, one of my red flags is the time estimate of "1-2 weeks". That's the off-the-cuff estimate that people give when they have no idea how long something will take. "A week or two" is "I can't imagine it would take very long, but my imagination isn't very good" ;)

ChrisMarshallNY 5y ago
A classic: https://www.youtube.com/watch?v=qLcjUmBncZ8 https://www.youtube.com/watch?v=qLcjUmBncZ8
drdec 5y ago
Before it became a video game, Fortnight was a popular facetious codename for projects at my employer.