3 Key Software Principles We Must Understand

1. Principle

You "Ain't Gonna Need It! (YAGNI)

Coding is about building things.

When Google+ launched, Mark Zuckerberg - founder of Facebook - was one of the first who created an account in the social network that was aiming to take his own down. He added just one line to the About me section: »I'm building things.«. I honestly think that this is a brilliant sentence because it describes the pure essence of coding in a few simple words. Why did we decide to become a coder? Enthusiasm for technical solutions? The beauty of efficiency? Whatever our answers are, it may not be »building the 1.000.001th corporate website with standard functionality«. However, most of us are making money that way. No matter where you are working, you'll likely be confronted with boring and repetitive tasks every now and then.

80% of the time spent on a software project is invested in 20% of the functionality.

Then we gonna need principle (YAGNI) deals with these tasks. It basically translates to: If it's not in the concept, it's not in the code. For example, it's a common practice to abstract the database access in a layer that handles the differences between various drivers, like MySQL, PostgreSQL, and Oracle. If you're working on a corporate website that is hosted on a LAMP stack, on a shared host, how likely is it that they will change the database? Remember that the concept was written with a budget in mind.

If there's no budget for database abstraction, there's no database abstraction. If the unlikely event of a database change does occur, it's a natural thing to charge for the change request.

We may have noticed the difference between You ain't gonna need it and DRY-driven modular architectures: The latter is reducing complexity by dividing a project into manageable components, while the former is reducing complexity by reducing the number of components. YAGNI is similar to the KISS principle, as it strives for a simple solution. However, KISS strives for a simple solution by trying to implement something as easy as possible; YAGNI strives for simplicity by not implementing it at all!

Theodore Sturgeon, an American sci-fi author, stated the law: »ninety percent of everything is crap«. This is a very radical approach, and not overly helpful in real-world projects. But keep in mind that "crap" can be very time-consuming. A good rule of thumb is: roughly 80% of the time spent on a software project is invested in 20% of the functionality. Think about our own projects! Every time I do, I am surprised by the accuracy of the 80:20 rule.

80% of the time spend on a software project is invested in 20% of the functionality.

If we are in a company that is notorious for tight deadlines and imprecise concepts, this is a powerful strategy. We won't be rewarded for implementing a database abstraction layer. Chances are that our boss does not know what a database abstraction layer even is.

While this concept may sound simple, it can be hard to differ the necessary from the unnecessary parts. For example, if you're comfortable with a library or a framework that uses database abstraction, you won't save much time in dumping it. The key concept is another way of looking at software: we're trained to write future-proof and maintainable software. This means that we are trained to think ahead. What changes may occur in the future? This is critical for bigger projects, but the overhead for smaller ones. Don't think into the future! If a small corporate website does fundamental changes, they may have to start from scratch. This is not a significant problem compared to the overall budget.

Planning a Project

When we are preparing our to-do list for a project, consider the following thoughts:

• Achieve lower complexity by reducing the level of abstraction.
• Separate functionality from features.
• Assume moderate non-functional requirements.
• Identify time-consuming tasks and get rid of them.

Let's go a little bit into detail!don't wrap a database driver around a database abstraction layer. Be suspicious of everything that adds complexity to your software stack. Notice that abstraction is often provided by third party libraries. For example - depending on your programming language -, a persistence layer, like Hibernate (Java), Doctrine (PHP) or Active Record (Ruby) comes with database abstraction and object-relational mapping. Each library adds complexity. It has to be maintained. Updates, patches, and security fixes have to be applied.

We implement features every day because we anticipate them to be useful. Hence, we think ahead and implement too much. For example, many clients want to have a mobile website. Mobile is a term of wide comprehension; it's not a design decision. It's a use case! People who are using a mobile website are, well, mobile. That means they may want to access other information or functionality than a user who visits the site laid back at his desktop. Think of a cinema site: Users on the bus will likely want to access the starting time of upcoming movies, not the 50 MB trailer.

Bad concepts can often be identified by the lack of non-functional requirements.

With an appropriate budget, you would perform a dedicated analysis of the requirements for mobile. Without this analysis, you will simply provide the same information as is on the desktop site. This will be just fine in many circumstances! Because mobile browsers are very clever in adjusting desktop sites to their display, a radical YAGNI approach might be to not write a mobile site at all!

Non-functional requirements do not describe the behavior of a software, they describe additional properties that can be used to judge the quality of software. Since describing software quality presumes knowledge about software, bad concepts can often be identified by the lack of non-functional requirements. Maintainability, a level of documentation, and ease of integration are examples of non-functional requirements. Non-functional requirements should be measurable. Hence, »The page should load fast.« is too inconcrete, »The page should load in two seconds max during an average performance test.« is very concrete and measurable. If we want to apply the YAGNI principle, assume moderate non-functional requirements if they are not mentioned in the concept (or if they are mentioned, but in concrete). If we are writing the non-functional requirements yourself, be realistic: A small corporation with 20-50 page visits a day does not require three days of performance tweaking - as the page should load fast enough because the server is not busy. If the corporation can increase the number of daily visits, a better server or hosting package shouldn't be too expensive.

Last, but not least, remember the 80:20 rule-of-thumb!

We have to identify the time-consuming parts. If a part is absolutely necessary, you have to implement it. The question should be: how will we implement it? Does it have to be the latest framework with a small community? Do you need to switch to the just-released version of a library if the documentation is not up to date? Should you use the new CMS, when not all extensions are available? How much research will be necessary to do so? »That's the way we have always done it.« is not an exciting approach, but it'll get the job done without surprises.

It's important to understand that all of this does not mean that we can start writing dirty code with hacks along the way! We are writing a lightweight application, not a messy one! However, You ain't gonna need it is a practical approach. If it would cause many lines of code to reduce a few lines of code duplicates, I personally think that we may relate efforts to budget and some unDRYness is ok. It's a small application. Hence, the added maintenance complexity is acceptable. We're in the real-world.

Let's come back to the initial thought: we like building things. When Beethoven wrote the Diabelli Variations, it was contract work. I don't think he made compromises on a budget. He ran the extra mile because he did not want to write average music; he wanted to write a perfect composition.

I'm certainly not implying that we're all geniuses and that our brilliance should shine through every line of code, but I like to think of software architecture as compositions. I'm a passionate developer because I want to build perfect compositions, and I want to be proud of the things I'm building.

If we want to be an experienced and business-proofed developer, we have to master the You ain't gonna need it principle. If we want to keep our passion, we have to fight against it every now and then.

Principle 2 and 3

It Will Be Released Soon.....

Thanks For Any Help or Suggestion For Me Just Comment Down Below...