mjdease

I would love to be able to pay to get ad-free versions of podcasts.

Agreed, I've been on many projects where a client only had vague requirements and useful clarification only came in response to seeing the app.

This is reasonable, it's human, but does anyone have a good approach to applying an iterative development approach on fixed price contracts?

I've been on many fixed price projects that are "agile" in name only, general issues I've observed:

- Iteration on requirements becomes confrontational (pay for change request) making it difficult to build a good product as we all learn what does/doesn't work for users throughout development.

- Upfront estimate is inaccurate causing time pressure on development resulting in rushed work which negatively impacts code quality and team learning.

The traditional answer is to have the client commit to specific requirements and hold them to it.

But what I'd really like to figure out is a way to acknowledge evolution of requirements will happen so we can work _with_ clients to build great products.

I struggle because this seems incompatible with fixed price and large companies seem to only want to do fixed price.

Regardless of the demonstrated use case, these principles can be applied to improve the performance of web pages that use JavaScript

Here's an alternate list with English resources: https://github.com/dzharii/awesome-typescript

And I code in 42 character width, so those are short lines

I've never heard of an approach like this, how did you settle on 42? I'd be very interested to see an example if you have some code hosted somewhere?

My initial reaction is 42 is too short and would encourage terse non-descriptive naming and be a pain to deal with long strings.