Ten years ago I wrote my first program in Pascal. The fact that I could make a computer do something was (and still is) mind blowing. I went home thinking how writing software is like art and math combined.
Fast forward to today that still holds true. Sure sometimes we end up doing mundane CRUD apps, but hopefully a lot of times we're trying to strech our mental muscles to come up with solutions to hard problems.
When working on projects people like to set deadlines. They are a great tool for setting expectations and creating a sense of urgency. But how does one set a deadline on something that's a non linear/creative process, like writing software? That's the question I've been pondering on recently.
Usaully when I work on a problem that's interesting and hard I fully emerse myself in it. I think about it for most of the day, I dream about it and I eat it. Any deadline I put at start will likely become irrelevant three days from when I said it due to the fact I discovered 55 other things we need to think about and cover in our new feature.
Here are two things that work lovely when there is a chance deadlines might not get met:
Reduce The Scope Of A Feature/Project
When you realize you can't make it on time due to the fact that the problem you're trying to solve is a dragon instead of a bunny, reduce the scope.
It's better to ship working software with reduced scope, then be late, get stressed out and ship something that's half baked.
If you ship a feature with reduced scope, that is working and can be tested with customers, one can leverage power of agile to improve it over time. This way you'll have more time to work on it, build it properly and see what your customers really want. That's a win-win situation.
Who knows you might end up not needing all of those bells and whistles you originally thought you need?
Don't be a hero
When things get hard and complexity creeps in, ask for help from your fellow team mates. That's not because you can't do it on your own but because things need to get done and you won't be able to finish it on time alone.
Balancing software development with predicting when that development is going to be done is something people have college degrees on, but hopefully things you just read helped you out at least a bit.
Auf Wiedersehen 👋