Get Great at Being Simple #

Every engineering team member is responsible for quality software, and by making everyone responsible for quality software, all team members must be able to prove that their work on the software is moving the finished product into the hands of our customers and adding value. All team members are accountable for quality throughout the software lifecycle.

How do we address quality? By focusing on being simple. From deciding what we want, down to programming it and getting it right, software development can be very complex - yet we do best when we can find simplicity in how we work.

Simple is good. Simple allows us to focus on delivering the one thing that will totally delight our customers. When we do one thing well, rather than several things as well as we can, the outcome will always be better. If we deliver on those tasks that will make a big difference, imagine how much more productive we can be. Simple allows us to focus our energy.

Simple isn’t easy. It takes hard work to find the one thing that you need to focus on: trying to work out what the problem you are trying to solve is. It’s too easy to say “…and then we can add these additional features too.” It’s hard not to continually tweak a good idea until it becomes confused. Simple is all about bringing clarity to our work.

Simple lets us be agile. Keeping things simple allows us to back up, learn from our experiences, but not be so committed that we can only continue in one direction. Simple enables us to adapt.

Sphera’s principles for effective software development provide a powerful way to manage complexity and allow us to keep things simple.

Provide Noticable Value #

If a tree falls in a forest and nobody’s around to hear it, does it make a sound?

Every user seeks value and every software developer should make sure to add understandable value to the newly developed solution or to increment such value in an already distributed solution. Every time developers get their hands on a project, they must acknowledge the fact that someone else will use and take advantage of what is being produced. Therefore, they’re expected to design not only an industry-responsive and industrially strong software, but one where the value of which is recognizable and easily ostensible. There are always third-parties that will have to understand what they have been given. Code with the know-how of a software developer but with an eye or expectations of a user.

D R Y #

DRY, (Don’t Repeat Yourself) is vital to understand. It’s the principle based on the strategic approach to “divide and conquer.”

Initially, the complexity of large software projects can be really overwhelming. Because of their complexity, such projects may take too much time, resources and efforts. In order to manage this type of situations, a good strategy would be to try to shrink the complexity by dividing the workload or the system into smaller subsystems and components. As engineers divide systems into components, and, further, components into subcomponents, you will arrive at a level, where the complexity is reduced to a single responsibility.

K I S S #

Keep it Simple, Stupid (KISS). Software works best when it’s made simply. To interpret it differently, KISS indicates that the simpler the system is, the easier it operates. And here, simplicity may well be understood as a software which is more easily manageable and less error-prone.

Simplicity doesn’t mean a lack of internal features. These shouldn’t be neglected in the name of simplicity - the most well-crafted and simple designs simultaneously discard any lavish “decoration”, require a lot of work, knowledge and craftsmanship.

Y A G N I #

You aren’t gonna Need It emerged as a cornerstone to Extreme Programming. The principle says, “Always implement things when you actually need them, never when you just foresee that you may need them.”

Coders should create code only when such code is required. This doesn’t mean you shouldn’t think about future use cases and ensure the system is flexible and capable enough to accommodate them–they just shouldn’t be coded.

S O L I D #

SOLID approaches are a set of solid programming practices that are used whenever creating software here at Sphera.

• S - Single-Responsibility Principle: a class should have one reason to change, it should have only one job.

• O - Open-Closed Principle: objects or entities should be open for extension, but closed for modification.

• L - Liskov Substitution Principle: every subclass/derived class should be substitutable for their base/parent class.

• I - Interface Segregation Principle: a client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.

• D - Dependency Inversion Principle: entities must depend on abstractions not on concretions. Essentially, a high level module must not depend on a low level module, but they should depend on abstractions.

Think #

Undoubtedly this is placed among the key principles behind building stable and effective software. Thinking clearly, rationally and logically is essential when developing solutions.

When a developer is reasoning and looking at things not only objectively but carefully, then this person is more likely to develop clean and effective software which can become the central measure for progress.