

I make shitty software with bugs – we all do - ibrad
http://idiallo.com/blog/2014/01/shitty-software-with-bugs

======
bdamm
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.

------
igordcard
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.

------
sophacles
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...).

~~~
venomsnake
One of the problems of dogfooding is knowing when to stop. Because you could
just get used to some of the quirks or find workarounds.

~~~
sophacles
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.

------
BlackDeath3
It sounds like nobody even tried to use your updated tool. How would they know
if it was awful?

------
whyme
While we have all been there, we may not all be there according to our own
measures.

------
thenerdfiles
"Bug-Driven Development"!

That's all I have to contribute to this discussion.

------
yaccz
wow such insight much deep very agile programming used

~~~
rhizome
Really?

