Menu

episode #5: YAGNI

| Isaac Sesi and Sam Moorhouse | | 63 | 645

00:00:00

Yagni is a Design Pun popularized by Perl developers. Effectively, what it boils down to is this: Don't Build Code That You Don't Need!

agileyagnidesign


This Episode is called Clash of the Titans because two of the people I’ve really looked up to over the past couple of years are in the building. We have Isaac Sesi, An award winning Ghanaian entreprenerd and Sam Moorhouse, the Founder of Global Code.

Isaac Sesi: Thank you, really happy to be on the podcast. I am Isaac Sesi, a software engineer (dunno if I should call myself that yet.), an entrepreneur, and an embedded systems engineer. I run two startups in the Agric Space and I’m interested in Education and Agriculture. Really happy to be here today.

Sam Moorhouse: My name is Sam Moorhouse. I’m a British software engineer and I run a program called Global Code, an annual summer program based here in Ghana. This year we are teaching computer programming in Cape Coast and Legon and KTU in Koforidua.

Before I launched this podcast, I used to record my conversations with developers on certain topics in tech. One thing that kept me from releasing the audio files on my site for the podcast was the simple urge to build a real-time commenting system first. It took me a very long time to figure out I didn’t really need that feature because people were just concerned about accessing the content. That’s a bad way to approach building anything. So today, we’re going to talk about an Agile method called YAGNI.

Sam Moorhouse: So YAGNI is You Ain’t Gonna Need It. It was popularized by perl developers because of the nature of their programming language, who invented/popularized what we would now call Design Puns. And YAGNI was one of them. Effectively, what it boils down to is this: Don’t build code that you don’t need. There’s a whole class of Software Engineers that we call Architecture Astronauts. When faced with a problem, they try to build the structure and framework for solving the problem instead of solving the problem directly. Sometimes it’s a pitfall junior developers fall into. And it’s definitely something that you find senior developers fall into. As a developer, if you keep YAGNI in mind, it forces you down a path of solving the problem you have.

Isaac Sesi: I’ll look at this from a different perspective. In my third year in University, my friends and I set out to build an app that helps students get access to past examination questions on their phones to prepare for examinations. We were so obsessed about building new features that for a whole year and a half, we hadn’t actually launched the app. Along the line, we learned better software design principles which enabled us to build a Minimum Viable Project (MVP) upon which other features could be added as needed. That’s my first experience with YAGNI: we were building stuff no one was going to use. It saves a lot of time, money, and sanity to build stuff you need incrementally as time progresses.

Do you think that adding that semi-formal structure around your development processes forced you down a path where you have to release?

Isaac Sesi: In the beginning, that was true. But as time went on sometimes there wasn’t really anything to release. But as soon as there was something significant to release, we did.

In a Nutshell, employing YAGNI helps you to

  • Deploy quickly
  • Better Test/Feedback driven development
  • Gives that self-fulfillment of being able to deliver on time
  • Create more value with less code
  • Reduces amount of rework

Is it just a common pattern with self-taught developers, or is there and underlying fundamental trait of perfectionism in people that makes them violate YAGNI often?

Sam Moorhouse: I don’t know. I’ve been an enterprise software engineer for 10 years. I’ve got a very classical software engineer’s education: I had a computer science degree, went into a job where I worked as a programmer for 10 years. I worked with mentors, I paired with people, we did TDD, and now I’m an instructor so I teach people how to write code. I was self-taught for about two and a half years before I went to the university but I barely remember that. However I’ve seen the pattern of developer writing code they don’t need for all kinds of reasons GOOD and BAD. A bad reason could be “The more code I write, the more valuable I become.” Good reasons like writing the interface for a new class in Java with all of the public methods just in case you may want to abstract certain parts during the course of your development period. A couple of things I think have helped with YAGNI include

  • Refactoring tools for developers and IDEs have made it easier to create interfaces or abstractions of different classes.
  • The growth of usage of dependency injection frameworks that have made it much easier now to abstract the contract identifiers from the implementing class
  • Ease in creating new releases for projects and progressive strides in Continuous Integration and Continuous Deployment

Isaac Sesi: I think when people are self-taught, they don’t get the kind of training software engineers get. They usually just learn to code. That means they lack some of the information that goes into good software building. A lot of people are programmers and not necessarily software developers. That’s why it’s important to find a mentor when you want to learn on your own. I don’t think most people deliberately ignore YAGNI, they just don’t have access to that type of info.

What advice will you give to a newbie who wants to get started with YAGNI. How do they determine what they do not need?

Sam Moorhouse: A solution that works the best is to build a Spike which is a cut down version of the MVP that allows you to follow one path through the system from one point to the other, up and down. It allows you to test the connectivity in your infrastructure, and every layer of a layered application. And with each Spike you are certain one type of user request/feature works.

Isaac Sesi: While building based on recommended features may be good, it is also prudent to decide early on the minimum that allows you to test your value proposition and focus on that alone. Users can also flood you with so many self-biased features you may not need. Keep a log however of those feedbacks and ideas on Github as issues or Trello as cards or whatever while you are still validating the reviews.

Sam Moorhouse: Sometimes as developers we think the compiler is our only audience. Just remember your audience when you are writing code.

Every line of code we don’t write is dollars we didn’t spend, and time on the calendar we get back for free.

– Tim Evans-Ariyeh

 

As a developer, your foucs and your aim is writing code, but the reason you’re in also in the room is to solve a business problem
Writing more code doesn’t always portray your productivity
Every line of code we don’t write is dollars we didn’t spend, and time on the calendar we get back for free

YAGNI by Isaac Sesi and Sam Moorhouse

Comments


Please Login to comment