One of the three main development principles is YAGNI, or You Ain't Gonna Need It. Why is this important? The most popular definition of planning is "what to do." In fact, everyone has a certain amount of capacity, so planning should be about "what not to do." It may be counterintuitive and highly unpleasant when you have to put off something essential for something more important to get done.
Free code review checklist and best practices
DownloadOne of the three main development principles is YAGNI, or You Ain't Gonna Need It. The other two are KISS (Keep It Simple, Stupid) and DRY (Don't Repeat Yourself). These principles, much like programming paradigms, provide opportunities for growth by allowing entities to exist without labour.
According to Ron Jeffries, one of the three founders of the Extreme Programming software development methodology and Agile Manifesto:
Always implement things when you really need them, not when you just assume you need them. - Ron Jeffries
Why is this important? As with the KISS situation, it's about money — developer time is very valuable. The customer wastes their time and money by doing something that won't be needed until later. Every business always wants more than it can afford, so every choice of functionality developed is one between what gets done and what doesn't. This is a business decision, not a technical one.
This is the most neglected guideline in software engineering, unfortunately. Sales promise 90% + ranking in Google Page Speed for sites with 10 users per day, developers build a microservice architecture for MVPs that can easily handle thousands of requests per second common, and marketers write articles about must-have life hacks for every business, which actually require huge money. Being in such an information environment, customers begin to demand all this from developers because they are sincerely convinced that all this is needed. It's doubtful we'll be able to break the loop, but we may build a center of rationality and efficiency around us.
Unfortunately, doing what we need later isn't a realistic scenario. There are also two additional situations that are even worse.
Firstly, the functionality may not be needed. We confuse foreseeing with need. What is the probability that the developer knows exactly what will happen to the customer's business in six months? Somewhere 0%. Even a customer who knows his business much better cannot predict the future. Therefore, if the developer starts doing something that is not in the requirements, it will most likely never be needed.
Furthermore, features are expensive, both to develop and maintain. We waste money on features we don't need and spend more to keep them functional because it complicates the system, which is also against the KISS principle from Extreme Programming.
Also, the functionality may turn out to be necessary but not done as it should be. The reason for this is the same as in the case of an unnecessary function. The developer cannot know what will happen to the customer's business in half a year and how its users will interact with the system. So, along with maintenance costs, there will be refactoring and rewriting costs.
Features that aren't actually necessary are a huge source of waste. There will be additional costs in each of the three scenarios.
The most popular definition of planning is "what to do." In fact, everyone has a certain amount of capacity, so planning should be about "what not to do." It may be counterintuitive and highly unpleasant when you have to put off something essential for something more important to get done.
What is the most frequently asked question in your workplace? "Can we do this tiny thing by the end of the week?" Yes, we can, but we must first choose what to eliminate from our scheduled tasks. It's the only correct option, yet many responses with, "Well, let's give it a try."
Based on past information, team velocity is one of the most important indicators in Agile planning. Nobody can cheat on velocity without suffering the consequences. Attempting to speed up a team will result in a productivity drop due to overloading.
When you should say no, say no. Decide what you won't do instead of what you will. Drop less important tasks without feeling guilty. The art of maximizing the amount of work not done is essential.
Avoid writing additional methods
Ron Jeffries used as an example that you don’t need to write methods for a class if you don’t need them now. The YAGNI principle helps you reduce code bloat by resisting adding features every time you write a method, function, interface, etc.
Don't overdo it by adding additional acceptance tests and acceptance criteria
The next level is Acceptance Tests and Acceptance Criteria. You don't need to come up with additional ones if you don't need to. For example, acceptance tests determine that the buyer can choose from a list of US states where to deliver the goods. Is it necessary to make a field "country"? Of course, this is a reason for discussion with the customer, but most likely not. If the client only does business in the US, then having a "country" field will be unnecessary and cause at least two problems. First, you must consider what to do with the list of states if the country is not the United States and how to process or cancel purchases from other nations.
The developer has complete control over these two levels, but the task might not be necessary most of the time. One example is the need for various optimizations, which are several times more expensive than profits. Amazon said that every 0.1s of page loading costs 1% of revenue. Let's not consider the fact that it was in 2006 and was pulled by the ears because this thesis is very popular among customers. The problem is that Amazon's 1% revenue was $107m. Does it make sense for a $1m business if the cost of optimizing the next 0.1c is $20k? The developer can't control such requirements, but if he doesn't want to be asked why the project is taking so long and costing so much, he needs to try to influence the customer.
The greatest thing that customers can do during software development is to collaborate closely with the team. This will help ensure that the software meets their needs and expectations. Customers may provide comments, ask questions, and report any problems. Working together, the team and customers can produce a successful product.
It's not a waste of executives' time to get involved in software creation. By lowering risks, spending several hours each month saves hundreds and thousands of dollars over time.
Good code quality is a must-have if you want to be able to modify your code later on instead of having to start from scratch; otherwise, YAGNI won't work. YAGNI tells us that we should only make the bare minimum amount of features, not that we should skimp on quality. Code should follow the software development principles and practices of Keep it Simple, Stupid (KISS), Don't Repeat Yourself (DRY) and be written clearly with tests to ensure consistent high quality.
It's impossible to foresee the future. We still frequently believe we have a good handle on what's required for our project's next step. Even if you're totally sure that you'll need a feature, later on, resist doing it just yet. You'll end up doing more work than you anticipated. Also, remember that it's okay to put off design decisions until later because you will have more information then. Following the YAGNI programming principle, you can agilely respond to change because your code is clean and easy to refactor and evolve.
VT Labs does agile development for Shopify stores, to move faster than competitors. You get store improvements every week and can change priorities anytime.
