At my first programming job I was at an ISP and was making the bandwidth provisioning and enforcement system. I was trying to tell the networking operations guys that it was pretty good these days and they said "Oh - OK we are putting the dev team behind it moving forward". Apparently my face was priceless. I know that sinking feeling in my gut changed my mind about a lot of things that day.
Dogfooding is good - it certainly changes how you think about things anyway.
It isn't sufficient for good software, but may be necessary -or at least when possible (sometimes you make software that has no direct application to your life...).
Or just forcing yourself to keep an open mind about pain points for others. Make notes of the "quirks" when you notice them immediately, similarly any work around should be filed as a bug. That way even if you get used to it, you know it wasn't always the case.
I completely agree with your opinion regarding being your own customer. Besides being the first customer of the system, it is also important to continue being so. When I created my first Android app, Tabata Trainer, I did it because I wanted to time my Tabata workouts while learning how to code for Android. I didn't even think about publishing it. Fortunately, the fact that I was the only customer of my app automatically made me aware of the most important blockers and bugs that would prevent any other person from using the app as well. It was after that that I realized I could actually publish it, and was surprised to see the results afterwards. However, many times when I added a new feature and didn't use it for myself (because I wasn't doing tabatas anymore), some people would report back or rate negatively. So, if you keep on improving or product, keep using it, or it may go from hero to zero.
I keep wondering when software methodology will keep up with just how bad modern software really is. Software is always terrible - until it gets refined over time.
By this I mean bringing concepts such as testing directly into programming languages. It isn't enough to say what a program should do, we need to say what programs should not do as well. Some languages have tried (Eiffel?) but failed. Some approaches have worked but have put the effort in the wrong place (e.g. JVM enforcing bounds checking) or by making it too powerful in the wrong ways (e.g. aspect oriented.)
Go takes a step in the right direction by introducing unit testing directly into the tooling. But that's not remotely enough.
Agile doesn't solve the problem either, because it focuses on the idea of a releasable product every few weeks. Living the reality of agile, I gotta say, it falls on its face a lot. Sure, you can make some microscopic change to your product, but then QA has to do a full regression every 2 weeks.
Surely software engineering can do better than this.
10 comments
[ 2.7 ms ] story [ 38.0 ms ] threadDogfooding is good - it certainly changes how you think about things anyway.
It isn't sufficient for good software, but may be necessary -or at least when possible (sometimes you make software that has no direct application to your life...).
By this I mean bringing concepts such as testing directly into programming languages. It isn't enough to say what a program should do, we need to say what programs should not do as well. Some languages have tried (Eiffel?) but failed. Some approaches have worked but have put the effort in the wrong place (e.g. JVM enforcing bounds checking) or by making it too powerful in the wrong ways (e.g. aspect oriented.)
Go takes a step in the right direction by introducing unit testing directly into the tooling. But that's not remotely enough.
Agile doesn't solve the problem either, because it focuses on the idea of a releasable product every few weeks. Living the reality of agile, I gotta say, it falls on its face a lot. Sure, you can make some microscopic change to your product, but then QA has to do a full regression every 2 weeks.
Surely software engineering can do better than this.
That's all I have to contribute to this discussion.