Limit degrees of freedom in development
By William Narmontas,
Original article at Hacker Noon.
Potential degrees of freedom in what you are working on:
- Not knowing the tools well enough
- Not knowing the domain well enough
- Not having a clear scope
- Changing scope before a previous requirement is achieved.
Recently a colleague of mine was rewriting code from one language to another, and trying to make it add a new feature and trying to fix a bug in the domain logic. He was doing too much and making no progress.
Earlier in time, when I was learning Scala I was trying to implement a gaming statistics system with distributed facilities and all sorts of nice sweet ideas. But I got nowhere, so I kept for a while reducing and reducing my scope — to the point that only the immediate thing I am working on was the only degree of freedom to move in.
There’s a dual to this: if you are trying to meet too many constraints, then you’ll never get to a solution.
What a domain is: it’s the business problem you’re trying to solve. An algorithm. A user interface. The user’s needs. Finance or eCommerce or media publishing or…
New domain and new tools? Can be quite confusing. So fix every variable but one.
If you want to learn a new tool, use the domains you already know.
If you want to solve in a new domain, use the tools you already know.
This is how I came up with the ‘Essential SBT for Scala’ guide to allow a newbie to get started with SBT and Scala with minimal Brownian motion.