The Importance of Simplicity in Software Architecture: A Guide for Success

By | August 19, 2023

Free Coding Cliparts, Download Free Coding Cliparts png ...

In the fast-paced world of software development, simplicity in design and system architecture is VERY often overlooked as a critical component of a successful project. While there is a tendency to focus on performance, scalability, and other technical aspects, the truth is that simple architectures are more efficient and ultimately more successful in the long run. Why? In this discussion, we will explore the benefits of architectural simplicity, the reasons for complexity, and provide recommendations for driving simplicity in software architecture.

Benefits of Architectural Simplicity

Simple architectures offer several key benefits that contribute to the overall success of a software system.

Ease Cognitive Load

A simple architecture is easier to communicate and comprehend. Architects and development leads often do not consider the cognitive load required by developers to understand a system enough to effectively work on it without breaking everything they touch.

Just imagine if you took an auto mechanic from 1970 and asked him to understand and fix a modern EV like a Tesla or a complex gas-electric hybrid like a Prius? He (or she) would be utterly lost and would have to spend a ton of time just trying to figure out how the car works, before even trying to fix anything.

That’s what a lot of companies do today with really complex micro service collections, code as service and other widely diverse architectures. Before developers can even begin to work on such a system they have to understand a ton of complex concepts: languages, frameworks, containers, container orchestration, networking, scaling, cloud infrastructures API interfaces, message busses, and so on. Then they have to understand all the particular ways your architecture uses those tools. It is a huge learning curve, and slows developer productivity.

All of that is a far cry from the simplicity of a classic Ruby on Rails monolith, for example. In an architecture that’s a monolith, there are far fewer moving pieces, and you don’t have to understand containers, orchestration, deal with inter-micro service orchestration or any of the other problems created by more complex architectures.

I’m not making a stand on micro services vs monoliths here. Rather, simply stating that often times a simpler architecture will offer significant benefits over something overly complex that you probably don’t really need. At least not yet. Don’t build complexity until you really need it.

By working to define and implement a simple architecture with a smaller model and fewer drawings, developers and stakeholders can quickly grasp the architecture, leading to better alignment across teams and efficient implementation. It saves time, money and frustration to keep it simple!

Ease of Implementation

Simple architectures are often far easier to implement and manage in a production environment . They have fewer moving parts, interactions, and potential points of failure. Compare a monolith with an application server, a database and a caching layer like Redis or memcached. In this architecture, 3, maybe 4 key tools power the whole thing. It is super easy to understand how it works, and therefore how to run and maintain it.

While it may take more time to identify a truly simple design through trial and error, the overall implementation process is streamlined. It is worth the effort.

Simplified Deployment and Operations

Simple architectures are easier to deploy and operate. With fewer moving parts, the deployment process becomes very straightforward. Once in production, simple architectures can be easily scaled and monitored, leading to fewer operational challenges.

There are a ton of great tools to manage deployments using continuous integration and continuous deployment (CI/CD). Even something as simple as Jenkins works great – unless your architecture is super or overly complex. Overly complex architectures make deployments and coordinating the deployments of tightly coupled components time consuming and error prone. (Tightly coupled / poorly abstracted micro services are abominations and I’ll definitely have things to say about that in the future. )

Focus on keeping your build and deployment architecture as simple as possible. This combined with a straightforward system architecture can greatly simplify and streamline your CI/CD pipelines maintaining maximum efficiency.

Flexibility for Modification and Evolution

Simple architectures are easier to modify and evolve. By adhering to the principles of Agile practices and specifically LEAN – development teams can be more productive with fewer complexities to manage and fewer points of impact when making changes. This makes the process of change overtime much, much easier.

Never heard of LEAN – learn more here?

I’ll summarize LEAN – it is all about eliminating waste. Even if nothing else in the LEAN world appeals to you or suits your team, you should always be looking to eliminate wasteful work in your projects. I’ll be sure to write a LOT more about that in the future because in my experience companies and project teams waste a lot of effort on meaningless busy work. But I digress…

Understanding Architectural Simplicity

Defining simplicity in software architecture can be challenging as it encompasses various concepts and practices. Here are some key considerations to drive architectural simplicity:

Strive for the Simplest Option

When designing a software system, strive for the simplest option that meets the functional and non-functional requirements. This approach, often referred to as Occam’s Razor, emphasizes choosing the most simples solution among multiple possibilities.

Apply YAGNI (You Ain’t Gonna Need It)

Avoid designing for future requirements that may never materialize. Instead, focus on building what is needed at present and only that. By avoiding over-engineering, you can reduce complexity and unnecessary development efforts. The vast majority of the time you won’t need to do more.

The most common way this manifests is “building for scale”. For example, you are building an internal time keeping app for a large company of approximately 5000 employees. Spending a lot of time to implement clustering, sharing, auto-scaling and other large to huge scale focused capabilities is almost certainly a waste of time. Time keeping happens once a day x 5000 employees. One server should be plenty to handle that level of load. Maybe two.

If your company grows exponentially, or decides to sell the time keeping software – now you might have to consider scaling. But how likely is that? And how fast will that happen? You won’t simply wake up tomorrow and have 5 million users keeping time on that system. Nope. It will take months to years – you’ll have time to make changes for scaling.

Key takeaway: Do it when you need it – don’t anticipate a need u will never have!

Avoid Premature Optimization

Another aspect of YNGNI is over optimizing. Avoid over-optimizing the design at the initial stages. Start with concrete implementations and refactor into interfaces as needed. This iterative approach allows for better interface definition and function names, resulting in a more suitable level of complexity for the system.

Embrace Simplicity, Not Familiarity

Simplicity is not equivalent to familiarity. Embrace simplicity even if it requires using unfamiliar technologies or techniques. The focus should be on finding the simplest solution that solves the problem at hand, rather than relying on familiar approaches that may not be the most efficient.

Reasons for Complexity

Despite the numerous benefits of simplicity, software architectures often become complex due to various reasons. Here are some common factors contributing to complexity:

Complexity Sells

Complexity can be seen as a way to add value to a solution, showcase technical prowess, or support empire-building within an organization. However, complex designs can become difficult to build, maintain, and evolve, ultimately hindering the success of the software system.

Development is Fun

Developers often enjoy tackling complex problems and using new technologies. Developers also tend to do this to pad their resume with the latest and greatest technologies – even if they don’t fit the need of the business or a better more proven solution exists. This enthusiasm can sometimes lead to overcomplicating the architecture, as developers pursue exciting challenges and overlook the long-term implications of complexity.

Keeping Up With the Joneses

The ever-evolving technology landscape tempts developers to incorporate the latest trends and technologies into their designs. While innovation is essential, blindly adopting new technologies without considering the impact on simplicity can lead to unnecessary complexity.

Simple Is Hard

Designing simple solutions is often more challenging than designing complex ones. It requires a deep understanding of the problem space, available technologies, and prior design experiences. Maintaining simplicity over time requires continuous effort and vigilance against entropy.

Organizational Structure

The structure of an organization can influence the complexity of software architectures. Conway’s Law states that the architecture of a system often reflects the communication structures within an organization. Complex organizations tend to produce complex architectures.

Recommendations for Driving Architectural Simplicity

To achieve architectural simplicity, it is essential to adopt specific practices and techniques consistently throughout the software development process. Here are some recommendations to drive architectural simplicity effectively:

Perform Some Design Up Front

While an agile approach is valuable, some level of up-front planning and design is critical. Set an initial vision, align the delivery team and stakeholders, and continuously monitor progress to ensure alignment with the vision.

Design Throughout Delivery

Over time as you gain insight and experience, adapt the architecture in small, logical ways to ensure you can meet the business needs.

Architecture should be continuously evaluated throughout the development lifecycle. Be prepared to make course corrections based on changing requirements or new insights gained during implementation. Intentional architecture ensures that decisions are made deliberately, considering the larger vision.

Ask Questions, Often

Challenge assumptions, clarify ambiguities, and ask questions to gain a deeper understanding of the problem and requirements. Regularly question design decisions and consider alternative approaches. Communication and collaboration are vital for maintaining simplicity.

Understand Decision Tradeoffs

Recognize that all decisions involve tradeoffs. Consider multiple options for each decision and evaluate the benefits, challenges, and risks of each alternative. Understand the return on investment of specific requirements to make informed decisions.

Create Proof of Concepts

Use proof of concepts to gain confidence and verify the viability of architectural decisions. Start with minimal implementations to validate specific aspects of the architecture, and iterate as needed. Proof of concepts can help reduce complexity and uncertainty.

Communicate Effectively and Often

Clear and frequent communication is essential for successful architecture delivery. Utilize concise documentation and favor written documentation vs shared understanding. Regularly review the architecture with the delivery team to reinforce the vision and prevent misunderstandings.

Embrace Minimum Viable

Focus on delivering the minimum viable product that satisfies early customer needs. Avoid over-engineering and prioritize architectural features based on the most likely scenarios, rather than addressing all edge cases.

Make Architecture Everyone’s Responsibility

Encourage the entire delivery team to think architecturally, regardless of their seniority. Foster a culture where all team members are involved in decision-making and challenge design choices. A collaborative approach ensures that simplicity is embraced by all stakeholders.

By implementing these recommendations, software development teams can prioritize simplicity and drive architectural success.

Conclusion

Architectural simplicity is a critical factor in the success of software systems. Simple architectures are easier to communicate, implement, deploy, and modify. They facilitate efficient operation, scalability, and responsiveness to changing business needs. Despite the benefits, complexity can creep into architectures due to various factors.

To drive simplicity, it is essential to adopt a proactive approach that includes upfront design, continuous evaluation, effective communication, and a focus on tradeoffs. By making architectural simplicity everyone’s responsibility and embracing a mindset of continuous improvement, software development teams can build robust and successful systems.

Simplicity should be at the forefront of software architecture. Embrace simplicity, challenge complexity, and continuously strive for architectural designs that are as simple as possible to meet the goals. Remember, simplicity is the key to unlocking long-term success in software development.

The Reality of Return to Office Policies: Why They’re Failing and What Employers Need to Do

By | August 16, 2023

?Image Source: Pexels

The COVID-19 pandemic has forever changed the way we work. As the world grappled with the unprecedented challenges of a global health crisis, remote work became the norm for many employees.

But now, companies are pushing hard for a return to the office and it has become clear that the traditional full time in-office model no longer makes sense for a large part of the workforce – particularly those who’ve successfully done remote work now for quite _literally_ years.

The Disconnect Between Employers and Employees

One of the main reasons why return to office policies are failing is the disconnect between employers and employees. While many CEOs and senior leaders believe that in-person work is essential for collaboration and career development, employees simply don’t see the benefit.

Collaboration happens virtually now. Zoom/Teams/WebEx/Google Meet/whatever all make it easy to have a face to face conversion anytime with anyone on your team. Plus we have text chat tools like Slack or others making quick collaboration WAY quicker than physically tracking someone down, interrupting them and doing it in person.

A study conducted by economists at the Federal Reserve Bank of New York, the University of Iowa, and Harvard University found that remote work decreases collaboration and training for junior workers. I really doubt the findings are significant, let alone accurate. These large institutions are funded buy the same large corporations that want to drag you back into the office.

Instead of forcing employees back into the office without considering their needs and preferences, employers should take a more intentional approach to training and mentoring their newest hires using the virtual tools available. Simply assuming that time spent in the office automatically confers benefits in terms of career development and collaboration is ridiculous and makes no sense. If employers want cross training and mentoring to happen, they need to create programs to do this intentionally for both in-person and remotely.

The Myth of In-Person Innovation and Mentoring

Many executives argue that innovation and mentoring are best fostered through in-person interactions. However, this assumption is simply not be supported by evidence.

Kate Lister, president of Global Workplace Analytics, challenges executives to question whether they have actually measured the impact of in-person work on innovation and mentoring. Has any company really done this analysis? Or do executives simply like seeing butts in seats? I think it’s the latter not the former. I’ve read countless articles on this subject – as it’s one I’m passionate about. I have yet to see _any_ convincing proof that forcing workers in office improves mentoring over remote in any measurable way.

Through my personal mentoring work at Springboard I know definitively that online mentoring is very effective. I mentored more than 100 software engineering students during my time at Springboard with great results. Students learned effectively, we were able to collaborate over code easily, and I could answer questions with no problem – all virtually. And I wasn’t the only one. Springboard has hundreds of mentors helping thousands of students – all online very successfully. So I know online mentoring works because I’ve done it and I see it work.

Moving Beyond the One-Size-Fits-All Approach

The approach of mandating a specific number of days in the office for all employees is foolish and costly. Each team and individual within an organization has unique business needs and personal preferences when it comes to in-person work. Fixating on the number of days employees should be in the office fails to consider the diverse nature of work and the benefits of remote work for employees productivity and personal well being.

Instead of stupid mandates, employers need empower individual teams and leaders to determine their needs for their teams. Corporate in office mandates or hybrid mandates don’t make sense at all when employees just come to the office to be on Slack and Zoom all day working with offsite clients, or staff, for example. All too often this is the story told of employees forced to RTO. They suffer all the negatives of commuting, loud open offices, coworker distractions and office nonsense – only to really work virtually anyway.

The Failure of RTO and Hybrid Work Models

The failure of return to office policies can be attributed to a lack of flexibility and adaptability. Employers need to stick with remote work when remote work is productive. Don’t cause employee upset and turnover by forcing RTO for no actual business reason.

If your business hasn’t CLEAR and PROVEN benefits to in office, or occasional in office work, then a hybrid work model may work for your team. But don’t force employees to be in office just to meet some phony “in office days metric”. Make coming to the office have a real purpose or you will cause discord in your team.

The Future of Work: Adapting to Changing Realities

The COVID-19 pandemic has accelerated the transformation of the workplace. It has highlighted the need for employers to adapt to changing realities and prioritize the well-being and productivity of their employees. Return to office policies that fail to consider the preferences and needs of employees are destined to fail. I will cheer such policies that fail because the businesses that implement them don’t care for or consider their employees well being when they implement them.

Conclusion: A New Approach to Work

The failure of return to office policies should serve as a wake-up call for employers. The traditional office model is out of date. We no longer need be tied to location for a LOT of work, and we as a society should take advantage of that. The reduction in needless commuting alone will save costs, time, and climate impacts from all of the countless vehicles NOT on the road driving to an office.

Pointless Return to Office Fails, Shocker

By | August 19, 2023

I saw this article this morning on Fortune: “Bosses Regretting Return to Office Mandates”. My initial reaction was, well obviously!

For the past few months, executives pushing Return To Office (RTO) plans on remote workers has been all the rage. Pretty universally, workers are being forced to accept a “hybrid” approach which means you have spend 3 or 4 days in office and can work from home the rest. There has never been a good explanation as to why this is a good idea.

Obviously, remote workers hate returning to office. Why wouldn’t they? For 3 years now they have been working diligently from home and crushing it. For someone like me, I’ve been a remote worker almost entirely since 2004. I’ve excelled at my job and done great work for nearly 20 years from home. I’m not special in this regard.

But I can tell you one thing. I’m not regularly working from an office ever again unless you pay me an absurd amount of money.

Record Profits be Damned

Also, let’s not forget how many companies have posted record profits over the last 3 years. A freaking lot of them, that’s how many. Yet, somehow, now remote work is a problem even though companies are swimming in profits and cash.

Companies don’t become wildly profitable if their workers are slacking and not producing. So, clearly remote workers have been getting the job done and done well.

Nonsense RTO Policies

Now companies are forcing people back to the office, for no real reason other than because they say so. There are no studies or numbers backing the push. The job market has weakened a tiny bit so employers feel emboldened to make workers come back even if they don’t want to because they feel like they have more power now.

What is actually happening when these RTO mandates come down? The best employees who enjoy or prefer working remote will leave. They can find work anywhere and they will with a more progressive and thoughtful employer. There are lots great employers out there that understand the value of remote work.

But what about the “non-best” employees?

Best case for management: they will be pissed off but will abide by the mandate and come to the office. But, you won’t get the same level of productive work from them. Not a chance.

It’s pretty common on social media sites to hear that workers plan to give only the minimum after being forced into the office. Even if they don’t have that feeling or aren’t vindictive, you’re going to lose time with pointless conversations, drop by people disrupting flow constantly.

Plus the office is probably one of those freaking AWFUL open floor plan office full of noise, distractions and disruptions. Most offices suck for actually getting work done. We used to bitch and complain about cubicles when I started in industry 25 years ago. Cubicles would be SO MUCH better than the open offices we have now.

What to Do if you’re asked to RTO?

Ask why. Start there, and find out the reason. Then make a case for remaining remote. If you’re producing well for your company it shouldn’t be a problem to continue remote.

But if your employer doesn’t care and wants to force RTO – leave. Go find work at a company that is remote friendly. You don’t have to deal with the pointless and risky commute, terrible office environment, crappy food and annoying in office personalities. There are a ton of jobs out there, go find one that appreciates the work you do – not that your butt is warming a chair in their office.

Coding Tests – Revisited

By | July 29, 2023

It has been a bit since I’ve written here. Sorry about that, life has kept me busy, and work was all encompassing. But, I find myself now with more free time and I’m back in the hunt for my next position after being part of a large Reduction in Force at my old company.

Back to the “Fun” of Coding Tests

Now that I’m back in the market, I’m remembering the “fun” of coding tests. I mean, don’t get me wrong, I love to write code and solve real problems. But I find many of the coding tests out there are really contrived, or academic and really, have no bearing on whether or not you can write good code.

I say that as someone who’s been part of hundreds of interviews as an interviewer. I’ve been part of many interviewing processes that use these tests, and most of the hundreds of interviews in the past couple years used them. I put little weight on the results of the coding tests simply because I have seen how little their use is as a measure of someone’s coding abilities.

But, I recognize that I’m in the minority in industry with this opinion.

Make Coding Tests Useful

So I work to make the best of them when I am the one conducting the interviews. I challenge the candidate to talk through their thinking, and decision making. I ask questions on why they took a particular approach. I point out obvious issues. The discussion through the process tends to be at least a little useful this way.

When I’m on the other side of the table, I try to talk through my thoughts as I work the problem. This is so the interviewer can understand my thought process and decisions. I do try to make the process somewhat useful and demonstrative of my skill.

All this being said, since I’m back in the market, I’ve started spending some time at LeetCode preparing for these little tests. I’ve done all my submissions so far in JavaScript and I created a nice little Git repository of my work to date:


https://www.github.com/brianteeter/LeetCodeSolutions

In the repo you’ll find the problems I’ve solved so far. Use Node 14+ and mocha to run them. Also, I checked in Webstorm project files in case anyone else can make use of them. I’ve made this public so others could benefit. Take a look if interested.

My 2nd Patent as an Inventor has been issued! (Patent 11011258)

By | March 14, 2022

I’m proud to announce another patent where I am a named inventor has been issued by the US Patent Office. This is patent 11011258 – Systems and methods for data processing and performing structured and configurable data compression.

That is a long name, but essentially the invention patented relates to novel methods for encoding and compressing medical data. The challenge we were solving was that we needed to store detailed patient data on tiny storage devices, like NFC chips. So I came up with a method to compress the data in a unique way such that we could store an entire patient’s medical record in something as small as an 8 KB NFC chip.

You can read about the full patent here:

http://www.pleiotek.com/wp-content/uploads/2021/05/patent-11011258.pdf