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.
In a past life as a project manager for a custom software consultancy, we had a rule of thumb based on experience that a functional prototype[0] takes about 25% of a total project's budget.
Whether the contract was time & materials (preferred) or fixed bid, that 25% rule worked well as an early indicator that the project was likely to go over budget. It allowed us to have early conversations with the client about cutting scope or expanding the budget to cover the unknown complexity.
We'd also dramatically increase our rate to reduce our risk on fixed price projects.
[0] Barebones, ugly, but functional from end-to-end.
Thank you. That'd be like someone criticizing a coding example for a new language saying "What's the point of using OOP for implementing Tic-Tac-Toe? It's too simple to necessitate it."
I'm not criticizing the technique from the article. It's useful. I'm just expressing my confusion that the blog, simple as it looks, needs this JavaScript (and analytics are in a separate file from the one I'm referencing, it appears).
That 56K number isn't gzipped, gzipped it's only 18K (plus there's also some inline JS, some webpack boilerplate, and then analytics.js).
The reason for its size is my site is my playground. It's where I get to experiment with all the things I want to experiment with.
I also work on quite a few open source projects, which I usually test on my site before releasing them publicly just to make sure they work in production without errors.
40 was a little too small, and 42 has been OK in practice!
I find it’s helpful because beating any structure beyond maybe 5 levels deep is painful, so I am forced to refactor.
Names aren’t so much of an issue because of the single-file-per-repo and 150-line-target principles:
If your module only consists of 150 lines, there’s just not enough in your namespace to need long names. Essentially, you only ever work within a small, isolated piece of a huge flat namespace.
Long names are necessitated by the huge, deep API surface that the filesystem provides.
