Not to defend the indefensible, but why not make a couple of discussion points...
If you have a huge application and a high staff turnover you want to minimise the amount of information in your developers' heads. Strictly architected code can do this to some extent, and can go some way to reducing need for that other 'enterprise bane' - documentation. This is less of a problem in a startup type environment were you can find out about a particular piece of code by walking over to the kid that wrote it and having a chat.
Code generation (mentioned elsewhere on the thread) is another example of something that is less necessary in a small environment. Matching an enum to the contents of a database table or whatever can be done by convention to begin with, but it's less practical if your development team is spread across three timezones. Better to invest the time in letting computers do the work.
If you have a huge application and a high staff turnover you want to minimise the amount of information in your developers' heads. Strictly architected code can do this to some extent, and can go some way to reducing need for that other 'enterprise bane' - documentation. This is less of a problem in a startup type environment were you can find out about a particular piece of code by walking over to the kid that wrote it and having a chat.
Code generation (mentioned elsewhere on the thread) is another example of something that is less necessary in a small environment. Matching an enum to the contents of a database table or whatever can be done by convention to begin with, but it's less practical if your development team is spread across three timezones. Better to invest the time in letting computers do the work.