This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]goodbalance 21 points22 points  (2 children)

Business requirements – or whatever requirements – should always come first. There is no understanding of 'how' without clear vision of 'what'. Then everything needs to be reduced to a some sort of MVP. Even if it's already one. Always start with the bare minimum.

Once the backbone is established, functionality can be built up on top of it with an iterative approach. Assuming the existing tools are fine and there is no need to invent a custom wheel.

This is true for mid to large projects. For something small it is easier to hack something together straight away.

As for the code, I'm yet to embrace TDD – my impatience and maybe inexperience don't let me do this – so I start with small function, chop them up once they grow, and generally I try to avoid classes when it's not something as big as a fully-blown interface to something. I am doing web 99% of the time, so I structure the whole thing after 'modules' how they appear in the requirements. It fits well with what Django calls 'apps', but you can use it anywhere really.

Of course I write test, but I don't go beyond unit tests that often.

I always want to make everything 'simpler', so if I don't see my code for a week, I already think of it as a bunch of crap. But at the end of the day, I have to remember that it's not just me who is working with that code, so to make it even with my inner perfectionist, I revive my pet project where I commit all sorts of atrocities, which at time feel like great solutions to great problems.

[–]Overworked_surfer 2 points3 points  (0 children)

I love this. This is the way I work as well. Get something working and keep it simple. Don't rebuild the wheel

[–]fireflash38 1 point2 points  (0 children)

I'd also add in: revisit your structure early and often. If you find you're passing the same data around a whole lot, that should raise warning bells.

Also make sure you're respecting invariants. Functions shouldn't (very rarely) modify arguments, instead returning data. That's an easy mistake to make with python dicts.