If you’re thinking about these things, congratulations. You’re a SOLID thinker.

SOLID is an acronym for a set of object-oriented design principles whose goal is to help increase the good “-ability”’s of your code, such as readability and maintainability.

• Single Responsibility Principle: A class should have responsibility over only one part of the application. It should only have one reason to change
• Open-Closed Principle: A class should be open for extension but closed for modification
• Liskov Substitution Principle: The behavior of a class should not violate the behaviors of its base
• Interface Segregation Principle: A class should not be forced to implement any methods it does not need
• Dependency Inversion Principle: A class should depend on abstractions, not details

Before I was taught these principles and understood their importance, making the code work was really my only goal. If you name the code smell, I was probably guilty of it. Tight coupling, huge case statements, absolutely no unit testing, classes that were responsible for a million things in a million different ways…I’ve done ’em all.

But once I started thinking SOLIDly, I’ve found I was able to approach problem solving and writing code in a totally different way.

In this article, I’d like to present the solution to a problem we had at Buildium that involved a SOLID solution and avoided some serious code smells.

The Problem

My team received a bug that we were allowing properties with invalid postal codes to be entered into the system. Buildium supports property addresses in any country, so what we needed was a system that given a country and postal code value, could say if the postal code value was valid.

A non-SOLID thinking engineer may implement a solution like this:

public static class PostalCodeValidator
{
    public static bool IsValid(Country country, string postalCode)
    {
        if (string.IsNullOrEmpty(postalCode))
        {
            return false;
        }
        
        if (country == Country.UnitedStates)
        {
            return new Regex(@"^\d{5}([- ]{0,1}\d{4})?$").IsMatch(postalCode);
        }

        if (country == Country.Canada)
        {
            return new Regex(@"^[A-Za-z][0-9][A-Za-z][ -]{0,1}[0-9][A-Za-z][0-9]$").IsMatch(postalCode);
        }
        
        throw new InvalidOperationException($"{country} is not supported");
    }
}

Looks great, right? It’s not too many lines of code and works. And if there were only 2 countries in the world, this would be fantastic. But there’s not. It’s actually closer to 200. Think about this design at scale, having almost 200 “if” statements to handle different countries. This design is problematic for several reasons:

• There is a chance of unintentional changes being made to this class because this method handles so many cases
• Every time a change is made to this class, all callers of it should be re-tested
• Callers of this class are dependent on all the dependencies of this class. This isn’t a big issue here, but if this class eventually utilizes a 3rd party API or other means to validate postal codes, those dependencies are now inherited
• The readability of this code would be horrendous with all of those “if” statements and regular expressions everywhere

So instead of just creating 200 if statements, we thought about it SOLIDly.

• Single Responsibility Principle: There should be classes whose single responsibility is validating postal codes for a particular country. There should be a class whose single responsibility is matching the appropriate country specific validator to the request, getting the validation result, and returning it
• Open-Closed Principle: We should be able to support new countries by just creating new classes that validate postal codes for that country. The class that matches the appropriate validator to the request should not have to change
• Liskov Substitution Principle: We didn’t plan on utilizing inheritance for this one but if we did, we sure weren’t going to violate any base class functionality
• Interface Segregation Principle: All the classes involved in the system will implement small interfaces that define exactly what the class is responsible for, and nothing else
• Dependency Inversion Principle: The list of country specific validators will be injected into the class that matches a validator to the request. That class will be injected into clients that want to utilize it

The Solution

Here is the interface we created for the country specific validators:

public interface ILocalizedPostalCodeValidator
{
    bool Handles(Country country);
    bool IsValid(string value);
}

Here is a concrete implementation of the ILocalizedPostalCodeValidator interface for the United States:

public class USAPostalCodeValidator : ILocalizedPostalCodeValidator
{
    private const string Regex = @"^\d{5}([- ]{0,1}\d{4})?$";
    
    public bool Handles(Country country)
    {
        return country == Country.UnitedStates;
    }

    public bool IsValid(string value)
    {
        return value != null && new Regex(Regex).IsMatch(value);
    }
}

Here is the interface we created for clients to call in to:

public interface IPostalCodeValidator
{
    bool IsValid(Country country, string value);
}

Here is a concrete implementation of the IPostalCodeValidator interface:

public class PostalCodeValidator : IPostalCodeValidator
{
    private readonly IEnumerable<ILocalizedPostalCodeValidator> m_localizedValidators;

    public PostalCodeValidator(IEnumerable<ILocalizedPostalCodeValidator> localizedValidators)
    {
        m_localizedValidators = localizedValidators;
    }

    public bool IsValid(Country country, string value)
    {
        if(string.IsNullOrEmpty(value))
        {
            return false;
        }
        var handler = m_localizedValidators.SingleOrDefault(v => v.Handles(country));
        return handler?.IsValid(value) ?? false;
    }
}

This is a much more SOLID solution. Our IoC container can inject all implementations of ILocalizedPostalCodeValidator in to the PostalCodeValidator class, so at run time it can just find the correct validator for the request. Let’s see how this design addresses the problems described above:

• There is a chance of unintentional changes being made to this class because this method handles so many cases
• Nobody should have to touch the PostalCodeValidator class in this design. If a new country needs to be supported or an existing country needs to be altered, those changes only happen in one class. The surface area of change is drastically reduced
• Every time a change is made to this class, all callers of it should be re-tested
• Pretty much the same logic as above. The surface area for change in this system is small, so testing can be focused. The automated tests a developer writes can be focused purely on the localized postal code validator they created
• Callers of this class are dependent on all the dependencies of this class
• Because we’ve abstracted away dependencies and utilized loose coupling through interfaces, implementation dependency concerns are gone. The postal code validator doesn’t know or care how the localized postal code validators perform their validation. They could use a regular expression, string length comparison, a 3rd party postal code validation API, carrier pigeon, smoke signals, whatever. Those implementation details and their dependencies are only concerns of the classes which directly utilize them
• The readability of this code would be horrendous with all of those if statements and regular expressions everywhere
• Pretty clear that this is not the case any more

Conclusion

Thinking SOLIDly can lead to writing code that is less fragile and more resilient to changing requirements. It takes time to develop the intuition to create SOLID solutions, but it is career-changing once you do, it certainly was for me. SOLID solutions can also make the lives of other engineers better as well.

Imagine you were not on the team that created this postal code validation system, but now had to implement postal code validation for a new country. Would you rather add code to a huge class, or would you rather write a brand new class with only the code you need in it? Do you want to be chased down when there’s a bug with some unrelated part of a huge class because you happened to be the last person to change it, or do you want to limit the surface area of your change? Do you want to write tests that were purely focused on the code you added, and nothing else? The answers to these questions should indicate that you appreciate when other engineers think SOLIDly. And you know what they say…do unto others…right?

About the author:

Kevin is a Technical Lead at Buildium. He’s passionate about the rapid development and delivery of clean, maintainable code. He’s been in software engineering since 2006 across a variety of industries including property management, sales enablement, defense, and health care.

SOLID-ifying Solutions at Buildium was originally published in Buildium Life on Medium, where people are continuing the conversation by highlighting and responding to this story.

The container approach addresses scalability and supportability concerns by deploying applications and services to very efficient, tightly controlled runtime environments that are isolated from the underlying hardware and host operating system. This allows multiple containers to be run on a single system without the risk of one service affecting the others. Serverless computing takes this approach a step further by deploying the application to the cloud provider, which is then responsible for managing the underlying hardware, operating system, and containers while providing automatic scalability and failover.

In theory, these technologies provide the application developer with the ability to develop systems that can be easily scaled to meet whatever performance characteristics are required. However, making the transition from a monolithic architecture to one based on microservices is a nontrivial undertaking, and taking some steps to prepare your company for this transition can be invaluable.

Buildium’s own journey towards microservices has been a multi-year endeavor, and along the way we’ve learned some important lessons. In this article, we present three strategies we recommend for companies thinking about implementing a microservices architecture.

Strategy #1: Establish and iterate on a messaging infrastructure

As you begin to move toward microservices, your infrastructure will need to evolve substantially to support the needs of this new architecture.

One of the key components is messaging capability, which is the backbone of most microservice implementations — services typically communicate with each other by sending messages. There are a wide variety of options to consider based on your needs, skill set, timeframe, and budget, ranging from custom solutions to a basic message queue to a more comprehensive message bus. Managing this infrastructure is a complex process in itself, and introducing this at the same time you are introducing a microservices architecture adds a lot of complexity and risk. The more time you spend implementing and stabilizing this infrastructure before moving to microservices, the easier your transition will be.

We have established an architectural goal within our company of building systems as a collection of resilient, decoupled services that communicate via asynchronous messages. We knew what we wanted to do even though we weren’t sure how we were going to get there, but we did recognize that we would need a messaging infrastructure for scalability and resilience.

After experimenting with several messaging platforms we eventually decided to use Amazon’s Simple Queuing System (SQS). Over time, our team has extended basic SQS functionality by adding support for large messages, providing automatic message retry and eventual expiration, and supporting service flags that allow us to temporarily stop processing messages when a critical component of our system is unavailable. We initially implemented this functionality within our monolithic application, before we had begun implementing any microservices. This gave us confidence that we could manage the queuing infrastructure, so that queuing was largely a solved problem for us when we began to move to microservices.

Strategy #2: Start by going deep, not wide

One of the advantages of a microservice-based architecture is that you don’t need to be constrained to a single technology. Services communicate across well-defined boundaries such as a REST API or the structure of a message, and as long as the different components of your architecture agree on these communication points, they can be implemented using different languages, different design approaches, or even deployed to different cloud providers.

However, resist the temptation to make a lot of technology changes at the same time, particularly when you are starting out. You also need to consider the effort needed to develop and support services written across different technologies. This will depend to some extent on how your teams are structured — are they completely self-sufficient and capable of deploying their own code? If so, you can probably have looser boundaries on the technology decisions, but keep in mind that you also lose efficiency as each team needs to figure out how to deploy their code.

If the teams are focused more on implementation and you have a separate operations team that is primarily responsible for deployment (as we do), each addition to your technology stack introduces a new burden on your operations team; they need to figure out how to build, deploy, and manage several types of services. In this case, it can be more effective to write your first several services using a single technology stack. Once you have established a repeatable process for developing new services, extending your stack should be much easier.

Templates for Standardization

At Buildium, we have done this by creating a template project using the .NET Core Template Engine. Our template defines a common structure that is used for our microservices, with some customization parameters for optional features. Developers run the dotnet new command to create a new project based on this template. It has the basic scaffolding that most services will need, such as integration with our logging and error tracking systems, configuration management, database access, and queuing support. We believe that using this template will save developers time and increase the usage of the common patterns that we have implemented within the template. Further, as we move towards automating our continuous integration/continuous delivery (CICD) pipeline, services built with the template will be registered for CICD automatically or with minimal effort, allowing developers to focus on the code that is specific to the service rather than the common responsibilities of getting it released into production.

Strategy #3: Establish continuous integration and delivery as early as possible

This is a natural follow-on from strategy #2, although it is one that took us a long time to learn. Incorporating a new technology in your delivery process can be a lot of work, but investing in a standard, automated way to deploy your services is well worth the upfront cost. The goal as you develop a microservices strategy should be to minimize the friction needed to build a new service, and the process of deploying to production is a common source of friction. If each new service requires custom tooling to deploy, it will be difficult to scale past a few services, and your development teams will find it increasingly painful to work on new services. Establishing automated deployment that works out of the box for new services is a critical success factor in being able to scale a microservices architecture.

We recently started using Terraform to provision our environments using an Infrastructure as Code (IaC) approach, and we are now including Terraform configuration in our service template. This generates service-specific CICD configuration so that the service can be deployed automatically from the initial commit. Our goal is to be able to deploy a new service all the way to production very quickly — ideally on the very day the service is first created.

This early full deployment allows the infrastructure to be validated independent of any business logic, so that as the business logic is developed, it can be deployed without having to worry about infrastructure concerns. In short, spinning up a new service should be as easy as cloning a git repository. We aren’t there yet, although we are getting close.

This automation and standardization also provides new opportunities for efficiency and improved administrative capability. For instance, we are developing a dashboard to view service health for all of our services. We will include dashboard configuration in our IaC code in the service template so that each new service will automatically be registered with the dashboard.

Continuous Learning

Like many companies, we have built a large monolithic application over many years, and we are working to break it into smaller pieces that can be more easily understood and managed. Along the way, we have been learning a lot about how to effectively manage our infrastructure to be able to develop and deploy services quickly. Some key strategies that we believe are widely applicable and we recommend for other companies embarking on a similar journey include establishing a messaging infrastructure, starting by going deep rather than wide, and establishing a CICD process. As we continue to learn and improve our processes we will share other recommendations such as effective strategies for separating out microservices from monolithic code.

Author

Herky Gottfried is the Director of Technology at Buildium, LLC, where he is working to reimagine how we build modern software applications. Before arriving at Buildium, he held a wide variety of software development roles at several Fortune 500 companies. Herky is passionate about working in an environment that values diversity, puts its people and customers first, and strives for continuous improvement. He travels to Boston regularly from his home office in Oregon, and hopes to run the Boston Marathon in 2022.

Moving Toward Microservices: Strategies for Starting Off on the Right Foot was originally published in Buildium Life on Medium, where people are continuing the conversation by highlighting and responding to this story.

The property manager serves myriad constituents from residents to vendors to property owners. Their days are spent in firefighting mode. A resident calls in saying their sink is leaking; it snowed last night, and the association’s streets haven’t been plowed; the condo board would like to see the latest budget report (sometimes all at the same time). As the Head of Product, I think of situations like these all the time to try and get into the head of our customers.

The common thread in these interactions is the resident. But the reality is that most software providers in the proptech space build solutions by thinking about the properties that a property manager oversees. The fact is, if the property (or unit) is vacant, then the property manager isn’t making money. And if the property manager isn’t making money, they certainly won’t be able to deliver sustained value to their owners.

At the end of the day, the focal point for the property manager in today’s market ought to be the resident, from the first impression to the daily interactions — and everything in between. At Buildium, we believe this center of gravity in the industry has already shifted from the property to the resident.

This is a big shift. The industry has traditionally focused on the “unit” or the “door,” but the more we looked at the data we realized that, while it might seem subtle, it’s a completely different mindset. As we considered what this shift in perspective means for our customers, I realized we needed to rethink how we build software. Taking a resident-centric perspective for our customers’ customer means we needed to build tools and services from the resident, outwards.

What Today’s Renters Want

In our 2018 Renters’ Report, offering personal, empathy-driven customer services and tools as part of the living experience were identified as being key to attracting and retaining renters. This makes sense and fits with who our property managers are. They are small businesses that run on the relationships they foster with their customers. And these relationships are a real opportunity for the property manager. In the same Renters’ Report, half all renters who decided to move out were based on reasons that the property manager has within their control.

Another input that we need to take into account is societal changes. We know millennials are more inclined to rent than to own. Millennials are also digital natives and far prefer self-service options to solve their problems. In that same study on renters, we found that 87% of Millennials said they’d rather take care of the rental process online. So that’s one resident audience for us to consider.

On the other side of the demographic spectrum are the baby boomers, defined as people aged 54 to 72. While this demographic is less tech-savvy, they aren’t averse to embracing technology. 4 in 10 now own a smartphone, and 65% own a desktop computer. While these figures are lower than what we see in millennials we still live in a connected world. In 2018, the United States alone had 290 million internet users, which represent over 75% of the US population. And, perhaps most importantly, more than two-thirds of them told us that they preferred online transactions and communications in their living experience.

The question became, how do we help our customers serve a resident population with such a broad, diverse set of expectations and needs?

Reimagining the Resident Experience with Consumer-Grade Pillars

It actually caused us to view some pieces of our product with a much different lens. At the end of 2018, we embarked on an effort to evaluate our resident-facing experiences through this new point of view. We started with the most common tasks the resident needs to perform: paying rents or associations dues online and submitting a maintenance request. From a property manager view, we had provided these key capabilities through our existing resident site, but when we looked through the resident’s eyes it was a different story. Residents found it difficult to use and even told us it was lacking some capabilities.

Long story short, we decided to rebuild the site. And this time, we declared from the outset that this build would be founded on the notion of a consumer-grade experience. Why? Because this is what the residents experience on a regular basis in all other facets of their day to day with banking, retail, and communications. “Consumer-grade” is centered on an idea that Jason Fried put forth in his Basecamp’s Signal vs. Noise Blog. In it, when talking about the customer experience, he noted that the customer should achieve maximum value with minimal effort with minimal learning and hassle.

This became our mantra. To get us there, the team established five pillars to serve as guideposts. The new resident site needed to be:

1. Focused and Streamlined: Whether you’re tackling a sprawling workflow or a small UI enhancement, your work should save users time. By remaining concise and reducing their cognitive load, we bring clarity to their hectic days.
2. Intuitive and Familiar: Our users should be able to open up any Buildium page and feel like it’s part of a cohesive whole. Our application should be consistent — never disjointed. Each interaction should feel natural, seamless, and easy-to-understand.
3. Tailored yet Flexible: Our workflows should feel like a natural extension of users’ businesses. We need to be pliable enough to accommodate unique processes, but keep customizability to a manageable level.
4. Directive and Supportive: We help our users feel in control of their businesses, lives, and daily schedules by providing timely guidance. They can rest easy knowing that we’ve helped them make solid, well-informed decisions and can recover from errors with ease.
5. Universal and Accessible: No two of our users are exactly alike with an array of interests, skills, and abilities — and our application needs to feel inclusive and welcoming to all of them.

From Theory to Reality

We launched Buildium’s new resident site this past February. The experience embodies our goals of building consumer-grade experiences. We realized that the way to reach the maximum audience was through the web, but since we understand the millennial user we knew it had to be mobile responsive.

The starting point was designing mobile first (Universal and Accessible). Designing for the mobile device also forced us to think about simplicity. The form factor demands it. Mobile-first required us to hone in on the critical use cases that satisfy a simple, loveable, and complete solution. The use cases also need to be completed in the fewest steps possible (Focused and Streamlined). As we built out the experience, we also leveraged as many standard consumer design patterns as possible (Intuitive and Familiar). While we tried to simplify the experience as much as possible and leveraged known patterns, we knew the new users still needed an orientation to the experience (Directive and Supportive). We leveraged Walkme to help us with a short overview of the site’s navigation and capabilities.

With the new resident site now live, we are in feedback mode. User and pressure testing our pillars were fine in building the solution, but customer usage and seeing value are the true test. Have we achieved our goal of a consumer-grade experience? Beyond the aesthetics, have we built a site that lives into the empathy-driven experience residents crave? I don’t have any illusion that we nailed it on day one, but I do believe building from the resident out is the right way to make software that fits our customers’ lives.

Read more on Property Management Trends

Piyum Samaraweera

is the Vice President of Product Management at Buildium, representing the voice of the customer and bringing hands-on experience in implementing agile and product frameworks to help product organizations drive execution. Prior to Buildium, Piyum led the product management team at Constant Contact, and his career includes extensive experience at companies including Sophos and Carbonite, building software-as-a-service (SaaS) solutions at scale for small and medium-sized businesses. When not at work, Piyum enjoys spending time with his wife, daughter, and adopted children: Daisy and Napoleon (both dogs) and Oscar the cat.

Originally published at www.buildium.com on March 20, 2019.

Redefining proptech software from the resident outwards was originally published in Buildium Life on Medium, where people are continuing the conversation by highlighting and responding to this story.

On October 16 that was exactly the scene that look place at our Boston office when we participated in Guppy Tank, a hands-on volunteer experience aimed at providing a STEM project-based learning opportunity for Boston middle school students. Guppy Tank is part hackathon and part pitch competition, with the day concluding in a Shark Tank-style presentation. This the second year that Buildium has participated in the event run by Building Impact in collaboration with Tech Underwriting Greater Good (TUGG) and Boston Public Schools.

Thirty students from the Dennis C. Haley Pilot School were tasked with prototyping an app designed to solve a problem around healthy living, with our Buildians (our employee volunteers) providing direction. Buildians from marketing, product, engineering, customer support served as team leads, working with the students through the design process. The challenge ties in with the sixth grade STEM curriculum in Boston Public Schools and the intention of exposing students to a wide range of skills and lessons, such as design methods, market research, engineering, marketing, and application prototyping and design.

The app ideas included a junk food monitoring system, a healthy food recommendation app, and a mindfulness tool aimed at reducing stress (who couldn’t use that?). From there, the students (alongside their Buildium team leaders) moved through three different breakout sessions as they began to design their app.

Guppy Tank brought Boston middle school students to Buildium headquarters to come up with an original pitch for a new, healthy-living app.

First, the students focused on how they could begin marketing the app, which started with identifying the problem they were attempting to solve and determining who their target audience is. Once the students settled on an audience, they moved onto product management aimed at solving the specific problem. The students were encouraged to think beyond what makes the app “cool” or how they could potentially make money from it, but to focus instead on the features and functionality of the app. Finally, the students worked with their team leaders to physically design a logo and homepage for their app — this is where the students’ creativity kicked into high gear!

“The best part of Guppy Tank is being able to see how proud the 6th graders are as they start to understand what really goes into creating an app, and to see themselves in the process as future developers, UX designers, product people, and marketers. It really shows when, despite their nerves, they get in front of a crowded room to tell their peers and strangers all about their idea, how they worked together, and what problem they are solving,” said Laura Ciccone, Product Manager, who participated as a team lead.

The day ended with the three teams pitching their app idea to a panel of judges. Each student presented their idea with clarity and enthusiasm — the envy of any entrepreneur looking to pitch their idea to venture capitalists! Prizes were awarded for Best Pitch, Most Creative Design, and Most Interesting Problem to Solve.

Everyone in our Boston-based office ended the day inspired and energized by our Guppy Tank “undergrads.” We can only hope that the students left feeling equally inspired and will consider submitting their resumes to us in about ten years, give or take!

A day spent designing next-gen apps with Boston’s sixth graders was originally published in Buildium Life on Medium, where people are continuing the conversation by highlighting and responding to this story.