It is not smart to model everything in UML for instance when building software. It is not smart to model nothing and go straight to code. It is however smart to find exactly that something that is of importance to model and code.
Advice : What is that something? It is about the most essential use cases and in articular about the most essential scenarios through these use cases. It is about the components and in particular the parts of those components that realize these essential scenarios. Thus, it is about the essentials. Now you may ask what makes a scenario essential. An essential scenario is the response to the question: "what are the most important scenarios the system is supposed to do". Which scenarios exercise the critical parts of the architecture? Which scenarios need to work in order for us to say that the highest technical risks have been eliminated?
It is not smart to write requirements without caring that these requirements are testable.
It is smart to make sure the requirements also are test cases.
Advice : try use cases since they are also great test cases.
It is not smart to work in a waterfall manner, first specify all requirements, then do the design and the code, and finally test it all. If you do, you will discover serious problems with performance, architecture, usability too late. It is smart to first build a small skinny system and then build a little bit more, and a little bit more, before you release the system to customers. Each time you build something, you must be able to run, validate and test it.
Advice : use a controlled iterative approach such as the iteration practice in the Unified Process or sprints in scrum.
It is not smart to run off and build a lot of "stuff" before first assessing if you can source the whole or parts of the application (Open Source or commercial offerings).
It is not smart to develop software with a process that cannot scale if your system is successful and customers want much more. It is smart to use a way of working that is no more than what you really need, but that can grow as you succeed with the product.
Advice : make sure your process has a dial for each interesting process parameter so you can turn the dial to the proper position for your project.
It is not smart to throw out your existing process and adopt a completely new process. That is doomed to fail in most cases. Not everything you did in the past was wrong so why should you start all over. It is smart to improve your process in small manageable steps.
Advice : add one practice at the time.
It is not smart to find a shortcut that in reality becomes a detour, such as skipping requirements and going straight to code. It is smart to do enough requirements to find what to use to build your first increment, your skinny system.
In general it is not smart to be extreme in what you do such as: model everything or model nothing, follow a strict waterfall process or an unstructured iterative approach, throw out what you have and start all over. It is smart to be balanced to do what is needed right now but with an eye to the future.
Above I have given a number of examples. In each case, there are some ideas on how to think about being smart. And each case can be expanded further. You will become smart with experience, but experience on the other hand is not a guarantee for being smart. Of course eventually, it comes back to you.
Smart is not the same thing as being intelligent. You can be intelligent without being smart. And you can be very smart without being very intelligent.
Smart is not the same as having common sense. You can have common sense without being smart, but if you are smart you must have common sense.
Smart is to do exactly right, not to find a broad solution that is just about right.
Let us all become smarter. :)
- Posted By Ivar Jacobson