4 ms·

You're going cut corners either way, either because you made intelligent choices where to cut corners, or because you ended up being forced to do a shitty job o

You're going cut corners either way, either because you made intelligent choices where to cut corners, or because you ended up being forced to do a shitty job on whatever you were working on when time/money runs out. There is almost never enough time or money to do every single thing perfectly.

ben_jones 10y ago
Here's an alternative: don't make time a factor while you build a foundation, then, when time does become a factor, simply extend the foundation as far and as rickety as necessary knowing at the very least you have a rock solid foundation. Practical example: You're building a CRUD app. Start by implementing robust logging, monitoring, testing, containerization (if prudent), and a proven framework-environment, then create all your endpoints and your client application. When your app inevitably fails the logging, monitoring, testing, etc, will be a nice consolation prize.
- taneq 10y ago
  Just my own singular data point but I've found that time spent getting the foundation right is never wasted. By the middle of the project, that early investment in engineering has usually paid for itself many times over in terms of faster feature implementation, higher reliability, and less time spent debugging and head scratching. Not to mention the quality of life improvement that then knocks on into better attitudes and motivation.
- asimuvPR 10y ago
  To add: You can pretty much create re-usable templates of robust logging, monitoring, testing, etc. It makes things way simpler and cuts down development time. For example, I follow the same principles and "finished" a Django-based application in about twelve days (with a good amount of tests included). No corners cut. Just leveraged previous code/experience.
- makmanalp 10y ago
  The counterpoint here is that it's oftentimes hard or impossible to know what exactly you'll eventually be building before you build it, especially with something like a startup where experimentation until you get product-market fit is the norm, or a project which has an expected life of multiple years/decade(s). If you sit there pre-planning every last detail of something, that usually means you end up making a lot of assumptions that eventually turn out to be false. It can be a sad day if one day realize you that your entire code is structured towards doing stuff one way, and then your requirements are the opposite. This is true even when you think you've thought of every possible option - life has a way of being surprising. Specifically abstraction is a tool to be used strategically, not a blunt instrument to bash your code with. Rushing into abstraction can kill a good codebase because it's difficult to refactor code to extricate yourself from a bad abstraction. Also a lot of abstractions come at a cost, e.g. the build takes longer, there is more boilerplate to get a simple thing done, you need multiple servers and orchestration to run the app, etc etc I'm finding that the thing to do instead is to build things open to change and extension, but initially allow some inefficiency / repetition / stupidity in favor of less complexity. You build in complexity as you need it. Examples: Don't start with the fanciest logging stuff, do use a uniform function call that is easy to find / replace later on. Don't start with containers or even separate repositories, but do keep logic between areas of code cleanly separated such that you can pull them apart easily later, etc.
- hinkley 10y ago
  I believe you are close to the concept of reversible decisions. Those base tools you discuss are all things you can't just tack on later on when they suddenly become important.

ben_jones 10y ago

Here's an alternative: don't make time a factor while you build a foundation, then, when time does become a factor, simply extend the foundation as far and as rickety as necessary knowing at the very least you have a rock solid foundation. Practical example: You're building a CRUD app. Start by implementing robust logging, monitoring, testing, containerization (if prudent), and a proven framework-environment, then create all your endpoints and your client application. When your app inevitably fails the logging, monitoring, testing, etc, will be a nice consolation prize.

taneq 10y ago
Just my own singular data point but I've found that time spent getting the foundation right is never wasted. By the middle of the project, that early investment in engineering has usually paid for itself many times over in terms of faster feature implementation, higher reliability, and less time spent debugging and head scratching. Not to mention the quality of life improvement that then knocks on into better attitudes and motivation.
asimuvPR 10y ago
To add: You can pretty much create re-usable templates of robust logging, monitoring, testing, etc. It makes things way simpler and cuts down development time. For example, I follow the same principles and "finished" a Django-based application in about twelve days (with a good amount of tests included). No corners cut. Just leveraged previous code/experience.
makmanalp 10y ago
The counterpoint here is that it's oftentimes hard or impossible to know what exactly you'll eventually be building before you build it, especially with something like a startup where experimentation until you get product-market fit is the norm, or a project which has an expected life of multiple years/decade(s). If you sit there pre-planning every last detail of something, that usually means you end up making a lot of assumptions that eventually turn out to be false. It can be a sad day if one day realize you that your entire code is structured towards doing stuff one way, and then your requirements are the opposite. This is true even when you think you've thought of every possible option - life has a way of being surprising. Specifically abstraction is a tool to be used strategically, not a blunt instrument to bash your code with. Rushing into abstraction can kill a good codebase because it's difficult to refactor code to extricate yourself from a bad abstraction. Also a lot of abstractions come at a cost, e.g. the build takes longer, there is more boilerplate to get a simple thing done, you need multiple servers and orchestration to run the app, etc etc I'm finding that the thing to do instead is to build things open to change and extension, but initially allow some inefficiency / repetition / stupidity in favor of less complexity. You build in complexity as you need it. Examples: Don't start with the fanciest logging stuff, do use a uniform function call that is easy to find / replace later on. Don't start with containers or even separate repositories, but do keep logic between areas of code cleanly separated such that you can pull them apart easily later, etc.
hinkley 10y ago
I believe you are close to the concept of reversible decisions. Those base tools you discuss are all things you can't just tack on later on when they suddenly become important.