Often, when developing a project, you might find yourself taking very similar decisions over and over.
When facing a decision there are usually two (somewhat opposite) ways to approach the problem.
As a rule of thumb we try to reach a sweet spot between both poles, taking the best features of each side. Consider, for example, the following issues:
"I will have to carefully design this module while not consuming too much time and resources, since development should progress very quickly"
We believe skipping any of the software engineering phases will most likely result in a product of inferior quality, since you will probably fail to produce high quality software when designing without knowing *what* you are designing, coding without knowing *how* you are implementing, or deploying without having actually gone through testing.
That being said, you can't really go very deep into any of the phases if you really want your development process to be anywhere near agile.
Enter agile software engineering.
"There are 10 ideas/features we want to include in our product, although we will only be able to include 2 or 3 due to time constraints "
A good rule of thumb would be to only include those features which are tightly bound to the core of your product. Including features which strengthen the core can only help you focus on the important things.
You might find some of the features - which we assume to be outside of the scope of the "core features" - to be very cool, but how do you know your users are going to like it as much as you do? Only your own users can provide you with those features they are looking forward to.
"The implementation of this particular module leaves plenty of room for improvement. "
Again, why start optimizing before you know for certain what parts you should be optimizing?(bottlenecks, etc).
Furthermore, some optimizations may result in code which is more difficult to maintain.
So remember, think before you act, stay simple, be spartan!
