Skip to main content

software development

Time estimates

One of the hardest thing in software development happens already before any code is being written. Estimating how much development time some feature might take is, at it's best, a guesswork.

No matter how generous estimates are being made they are still almost always too optimistic. Even after the original developers estimate is doubled. Twice. On the other hand, on those rare occasions when the estimates are being beat they are being beated big time. In a longer project these are almost enough to compensate all the underestimates. 

Cheap until it's not

Many services to build things on the internet are really cheap to get started. Many even offer a free tiers that are more than enough for small projects to get started with, for hobby projects often more than enough to keep running them indefinitely.

These cheap prices can however be deceiving. Once you start having more data, more traffic and a lot of requests the price can go up really fast. The scale of things on the internet is huge. 

Demo effect

Every developer knows the demo effect. I'm sure it's common in other engineering disciplines as well and maybe even in other fields as well. The case is, that no matter how well prepared you are, how many tests you have ran and how perfectly everything worked on those times, when you show your work to others something unexpected will happen.

Despite thorough testing there can always be bugs in the code. And usually there is pressure to show some progress as early as possible. Management, customer or shareholders want to see things moving forward. 

Too DRY

DRY (Don't Repeat Yourself) is a good principle to make software more maintainable. It can also help code to be more readable and efficient. But it can also lead extra layers of abstraction and separation from the actual logic. Pure DRY should therefore never be the absolute goal.

Subscribe