|
|
|
|
|
|
by t43562
1094 days ago
|
|
|
Usually one understands a project poorly at the start and much better at the end. So to agree with the article I think it's unwise to make all your decisions at the point where you know the least. By getting something working you improve your understanding and then you can choose optimisations and abstractions in a judicious manner - no point in optimising things that end up having no impact and no point in introducing abstractions that in practice never will be used. There are those who imagine that you can completely plan work before lifting a finger and it's a problem to struggle with them sometimes. Another one is when some aspect of the outcome is big in people's minds. I was once on a project where we thought we'd be charging people based on their usage of the product. This made the reporting system very critical because if we messed anything up we'd be cheating our customers or giving them freebies. In the end we realised nobody wanted to pay that way so this huge design consideration which made everything much more complicated was gone. This sort of pattern happens often and it was a mistake to start that way. But that was a requirements mistake rather than a programming one and this is why your requirements are so critical. A single sentence in a document can double the cost of a project and your customers often don't realise that. |
|
|
It also happens at the product level - building features too early or too deeply for a poorly understood workflow; abstracting things that don't need to be abstracted for probably YEARS; over-engineering for major scale despite having no users; knowing that ONE DAY you'll need, say, multi-language support, so on Day 1 you over-complicate everything by insisting on a language framework etc.
Beginners lack the foresight of 'what this will look like at scale' or maybe better said 'why this won't work at scale', but that's ironically why they are better early on - speed matters a lot more than anticipating potential scale issues years later.