undefined | Better HN

0 pointsChrisMarshallNY5y ago0 comments

Good point, but I have found that just doing it right the first time works for me. In fact, I'm doing it right now. In the Xcode window, I'm building a test release that the team will run and review for usability issues and bugs.

If they find any bugs or issues, I fix/address them before moving on to the next function implementation.

The significant advantage that this confers, is that the app is constantly in "release-ready" form; although incomplete.

Useful, for when we want to ask people to give us money. We just get an NDA, loop them into the TestFlight group, and let them have at it. No need for chaperones from Marketing, or sacrifices to the demo gods.

0 comments

NateEag5y ago

Perfectly reasonable workflow.

I lean towards POCs these days because I have experienced the requirements turning out to be all wrong far too often. It's hard for people to know what they want or need before they can try something sort of real.

LandR5y ago

The problem i have is I get told to write a fast proof of concept. I make it clear that its hacky, poor quality code. Then ill be told to make it live to test it.

Then it ends up in production. Then they want to add stuff to it, which is a nightmare as the code is terrible.

Every time.

NateEag5y ago

I'm sorry. That sounds miserable. :(

Like I said - a proof of concept is only a POC if major features and plumbing are just missing.

You only build the parts you need to show the concept is possible. The bits you don't know exactly how to do already.

If it can be pushed to production usefully, it's too full-featured to call a POC, in my view.

ChrisMarshallNYOP5y ago

Yup. My experience, as well.

That's exactly why I work like I do, now.

Unfortunately, I can't do it when I'm working for anyone else. They never let me do it the way that I do it. I have to be doing it on my own.

It works. It really works, if I write top-quality code, the whole time; even if I have to throw away or drastically refactor/write production-quality code.

My experience is that the final product:

1) Is of almost jaw-dropping quality (it was tested thoroughly, the entire time),

2) Is tailored exactly to the needs of the end-user (which deviated substantially from their original requirements), and

3) Arrives very, very quickly (this always surprises people).

j / k navigate · click thread line to collapse

0 comments

NateEag5y ago

Perfectly reasonable workflow.

LandR5y ago

The problem i have is I get told to write a fast proof of concept. I make it clear that its hacky, poor quality code. Then ill be told to make it live to test it.

Then it ends up in production. Then they want to add stuff to it, which is a nightmare as the code is terrible.

Every time.

NateEag5y ago

I'm sorry. That sounds miserable. :(

Like I said - a proof of concept is only a POC if major features and plumbing are just missing.

You only build the parts you need to show the concept is possible. The bits you don't know exactly how to do already.

If it can be pushed to production usefully, it's too full-featured to call a POC, in my view.

ChrisMarshallNYOP5y ago

Yup. My experience, as well.

That's exactly why I work like I do, now.

Unfortunately, I can't do it when I'm working for anyone else. They never let me do it the way that I do it. I have to be doing it on my own.

It works. It really works, if I write top-quality code, the whole time; even if I have to throw away or drastically refactor/write production-quality code.

My experience is that the final product:

1) Is of almost jaw-dropping quality (it was tested thoroughly, the entire time),

2) Is tailored exactly to the needs of the end-user (which deviated substantially from their original requirements), and

3) Arrives very, very quickly (this always surprises people).

j / k navigate · click thread line to collapse