Geek Answers Handbook

Why is it so hard to force YAGNI?

I break this template all the time.

LAMB - You won’t need it

I'm just a junior developer, but I find that even older developers do the same.

"Well, this system can use it, and this one, so let the design be for it."

Sometimes I break myself, but most often I run. Does anyone have any advice on attaching to YAGNI or something I can do to better apply this design pattern during design and coding?

+7
design design-patterns yagni
source share
15 answers

Development of something

... completely different from

Creation of something.

Designing for something means that you are developing an application for further expansion if you need to write code (which is good ... it means that you make your software extensible and easy to maintain).

Developing something means that you are writing the whole piece now ... do you think that someone is actually going to use it or not. This is not necessarily bad, but it can be a huge waste of time.

Be careful what you do.

+24
source share

It has something to do with perfectionism. let it become perfect, let it be ready for all possible future scenarios.

This helps to be pragmatic and sober when deciding on the opportunities that he will need: then answer either “Yes” or “No”. Maybe not.

If there is no clear evidence, it will be necessary (this is on the agenda, this was set by the client), and you see that it is better to take into account the future functionality of your current design, leave it for now.

+8
source share

Just use TDD !!!

you rarely find yourself writing a test for a function that you don't need ...

+6
source share

Because YAGNI is a principle, not a panacea
Software development always involves balancing many requirements. It is not about correctly understanding one thing, and not making mistakes. Only YAGNII will not save your ass.

In this sense, YAGNI exists to avoid the following traps:

  • When you need a compiler, create a compiler - not a self-compiling compiler structure (Our strength is solving a common problem is also our weakness).
  • Do not underestimate implementation efforts.
  • Do not overestimate the life of your application and the stability of requirements.

Balancing competing requirements is difficult. But here's why, ”McConnell asked sharply,“ software development is development. ”

Because other principles are people too.
The principle of other principles - the more fundamental IMO - is the principle of least surprise and encapsulation of complexity: the public interface / contract of an object should be simpler than the implementation - otherwise, to properly call the function, I would need to learn more than I needed to do it myself . sometimes this means that your implementation must be complete.

One example (maybe not very good):

/// Estimates the time required to comlete the batch. /// If the time cannot be estimated reliably, the return value is -1 /// \returns [double] estimated time in seconds double EstimateDuration(Batch & batch);

- a simple contract. Oto

 /// Estimates the time required to comlete the batch. /// If the time cannot be estimated reliably, the return value is -1. /// This function does not support looping batches (right now, looping /// batches only run under a servicve account with no UI, so it not needed). /// Also, when the moon is full, the return value is -1, but an estimate /// is found in batch.JeffsEstimate. This value is used only by Jeff core /// build script which runs roughly once a month. /// \returns [double] estimated time in seconds double EstimateDuration(Batch & batch);

It is not a contract, it is a description of the item. (One could argue that the problems are due to excessive YAGNI or simply poor design, but perhaps because you have fully developed YAGNI)

Design does not hurt
Will the emergence of a flexible, "design phase" received something a bad name. However, to be worse than not planning at all, your plans must be disastrous. The biggest danger is not really bad plans, but an attempt to anticipate every problem and change the request. YAGNI is priceless here.

They are older, because I do not know them. Their tendency may be related to the ideology of the waterfall in the old school and the fear of change. Or maybe they are older people, because they know their job - they learned what parts you are doing now rather than later, and which parts can be sacrificed for the insanity of the future.

+6
source share

It's so hard to force YAGNI, because I think most of us have been bitten by the opposite problem, to find a system that is too complex or fragile to refactor to do what we want, but which could allow it with a little more prudence. Mid-range searches can be tough.

Generally speaking, if you think that “[xyz] may need it,” then this should clearly play a role in what you code. Even if you do not code for xyz support, then you should code in such a way that refactoring to add xyz support is as practical as possible. Sometimes this can mean creating something more general than it should be strictly. Knowing where to stop along this path is perhaps something that can only tell you information about a specific domain in combination with experience.

+4
source share

“Back to the basics” and “Simple is good” are a couple of phrases that appear to remind me to just dwell on the task and understand why I am creating this function or improving it, rather than doing restructuring or planning for a million things that probably won't happen. Where I work, my name is often used as a way to describe something too complex or overly complex, for example. "You jbed how to build this page." I try to keep it under control more, because sometimes it is useful, but not often enough to become my usual practice.

Sometimes, a requirement written in non-technical terms may be required. This allows me to know what I should show at the end, and not to worry about finer details, for example. system users are unlikely to read my source code and mock my use of any naming convention we use. They make sure that they work, and do what they need, and they want it done.

Another question: "Have they really asked for it?" and try to minimize assumptions about functionality. If it is not on the list, then leave it, although ask if they want it.

+3
source share

YAGNI really asks a question more. We, as senior developers, constantly violate YAGNI. This is truly a matter of "necessity." Do you need it? Define "need." I saw terrible balls of dirt designed using the YAGNI dogma.

Not that I think YAGNI is not useful ... you should always ask "Do I need this."

+1
source share

If you create a library / toolkit / platform / framework, YAGNI takes a different value.

You cannot be sure how other developers will use your tool, and sometimes it makes sense when designing with flexibility so that your product can be used in a wider range of scenarios. Future compatibility is also a huge consideration.

YAGNI is still used, but “it” tends to be at the meta-function level, rather than at the function level.

+1
source share

Remind yourself what you are trying to implement, and do not do more. You can do it with

  • clearly written user stories / requirements. If the "eligibility criteria" for your work are clearly defined, it is easier to judge whether something is or not.
  • someone (maybe himself) who expects you to finish quickly. This makes you sure that you are not leaving.
  • TDD
  • or something close to him.
  • daily racks (or more often) to make sure you don't go weed.
+1
source share

Well, yesterday I came across the same thing, and I had a big fight with one of the senior developers. I always try to design using "what if someone calls it, what if it changes to mm, etc.?"? and he is the other extreme. "Just make it work and FAST!"

The answer lies somewhere between his approach and mine. How do we get to the middle? Between trying to make a “perfect” design that people will appreciate or HATE if they have to change something in the future.

IMHO, the answer, at least when developing the module, comes down to the basic principles of object-oriented programming, such as defining intuitive interfaces. Interfaces must meet customer requirements. In the main interfaces for the module, there should be nothing that “solves” anything, except what is contained in the requirement. At least some level of "frills" is added because of "that if this changes, they need it tomorrow, etc." Can be deleted.

Everything that you plan to put, because you think that it MAY be used tomorrow by someone else, etc., should be discussed for hours! You must have good reason to add a "freebie" for someone who doesn't even have a name at the moment!

I still need a definitive answer to this question. Maybe from some architect who developed large applications and faced this situation 100 times :)

+1
source share

Design your applications well in such a way as to facilitate the implementation of future functions, but don't really implement the functions until you need them. How to do this completely depends on the project you are working on.

0
source share

I am in peer reviews and help to programmers. Another set of questions that ask your reasoning, quickly identifies what you think is necessary, but actually not.

0
source share

If you follow Agile, you can work on important material until you get to the point you don't need. By the time you get into the YAGNI material, you should have quite a few finished products. Then it comes to the point that you stop developing the material.

0
source share

YAGNI is often an afterthought. Just make sure you are agile enough to remove the self when the LAMB becomes apparent.

0
source share

We have a rule of thumb in our company: when we discuss the development of a new feature, the first question to answer is "Who really wants this?" if the client is behind this, we are trying to understand what he really wants, and if there are other ways to solve his problem (instead of adding a new function). If a team member asks for this new feature, he must have good reason for it. Among them are performance problems and marketing problems, and again we try to fully understand the request and discuss all possible alternatives before adding some new features to our code base.

0
source share

More articles:


All Articles