DEV Community: Tami Mandarino

Dear Fellow Developer, Please Stop using Emergent Design

Tami Mandarino — Fri, 03 Nov 2023 14:04:03 +0000

Dear Fellow Developer,

A little over twenty years ago, a group of guys went to a ski resort not far from my house and wrote the agile manifesto. Not long after, the entire industry transformed. We went from using the waterfall method of design to agile methodologies. Along with this transformation, eXtreme Programming (XP) gained traction as a new way to develop code. XP relied on a few tenets, two of which I will discuss here:

Pair programming
Emergent design

Back then, it was an exciting time to be a software developer. We'd been suffering with the weaknesses in the waterfall methodology and knew there had to be a better way. My team dove right into XP to give it a try. We wanted the perfect code promised in all of the XP evangelical articles. We paired up and tried to live the dream. The business, however, felt like we'd chopped their development team in half. What did we mean we needed two programmers on every assignment? That practice lasted about a month before we were told to stop.

As a matter of fact, businesses around the world didn't like pair programming, but developers recognized the value of tight feedback loops provided by pair programming. Thus was born the code review.

While few (if any) still practice XP, its legacy continues today in other ways. In addition to the code review, we were also given emergent design, a concept which sounded good on paper but resulted in decades of bad code.

For emergent design, the theory was this: you developed one requirement, wrote tests around it and moved on to the next requirement. When faced with modifying code, you were supposed to refactor ruthlessly, using unit tests to maintain the original requirement. This was supposed to cause the ideal design to emerge from the development, hence the name.

Unfortunately, no great designs emerged. In fact the opposite happened. Let's talk about how and why it failed so spectacularly.

First, there is a point in development at which it becomes no longer practical to refactor. When this point is reached, developers may choose to do a number of different things. Some patch the old code. Some copy and paste to provide a new pathway through the code. Almost all hack together a solution to the existing problem. Those hacks then become a pattern for future developers.

Another reason emergent design failed is design principles stopped being taught in dev shops. Junior programmers stopped getting the education they needed to use the emergent design methodology effectively. If someone doesn't know what good design looks like, they cannot refactor bad code into good. Instead, junior devs mimicked the bad choices of their seniors. After a couple of generations of juniors becoming seniors, the industry produced a bevy of "senior" developers who couldn't design their way out of a paper bag.

The code left behind from this disastrous era is a spaghetti bowl of bad choices and brittle classes. No one wants to work on the ugly legacy behemoth. Instead, they want to write green field applications, and unfortunately, many of them repeat the same mistakes they made in the legacy code base, because they continue to use emergent design.

While I recognize the inherent problems with waterfall's big up-front design, the industry over-corrected with emergent design and ended up in a place with little to no design at all. At some point, we must put an end to this madness.

Martin Fowler, one of the original architects of XP, wrote a keynote speech in the year 2000 called "Is Design Dead?" In it, he talked about evolutionary (emergent) and planned design. He compared the concepts behind emergent design to architecture, saying if you want to build a dog house, emergent design might work if you have a bunch of lumber, a rough idea in your head and a willingness to rebuild it if things go wrong, but what about if you're building a skyscraper? We all know a one-bedroom house wouldn't be up to code if it wasn't designed properly, but somehow we think our monoliths are going to be vast creatures housing our brilliance without doing any up-front work. We are wrong.

I have now worked in enough monoliths to speak unequivocally: emergent design is our industry's enemy #1. Even if people practiced emergent design the way it was intended (which they don't), it's not capable of working effectively within a large application, or even within a large class for that matter. It is not a forward-thinking methodology, and no brilliant design "emerges" from its use. What emerges is hacked-together spaghetti that degrades in quality the older it gets.

So how do we address these problems? The method I've found to be the most effective is using Domain Driven Design (DDD). DDD was introduced by Eric Evans in 2003 but didn't gain popularity in the industry until the era of microservices. DDD models software after business processes. Isolation of individual domains allows modularization, which lends itself well to a microservice architecture. While Vaughn Vernon has written multiple books about Domain Driven Design, the condensed version I find the most understandable is InfoQ's Domain Driven Design Quickly.

Whatever process you choose, be it DDD or another, I beg of you to abandon the practice of emergent design. Chances are you're doing it wrong, but even if you are doing it right, it's not a methodology that produces long-term quality results. Even the original architects of the methodology knew that to be true two decades ago, but human nature beckons us to take the path of least resistance, and so we've ignored the warning signs.

If you're reading this, please reconsider your use of emergent design. While we've lost the art of design in our decades of willful ignorance, we can resurrect good design practices. We can create frameworks rather than if-than-else nightmares. I believe in the brilliance of developers, which is why I'm writing this article. I beg of you to spend some time focusing on design and creating software of which you can be proud. We can and should do better, and we owe it to our future selves to try.

Happy coding!

HR is your Friend and the Stripper Thinks You're Cute

Tami Mandarino — Wed, 25 Oct 2023 14:03:45 +0000

Twenty years ago, when I hadn't yet worked with another single female dev, my male coworkers took me to the strip club. A bunch of men and I watched the strippers and squirmed, uncomfortable at the sexual atmosphere created by our location. With my rubbish memory, I can't recall much else. Luckily, none of my coworkers fell into the fantasy of having caught the eye of one of the strippers. However, I have heard male friends (more than once) make this claim.

Though I haven't spent much time or money at strip clubs, I've been friends with several strippers throughout the years. In case you're wondering, they aren't interested in dating their patrons, but if they can make you believe they are interested, they've succeeded. Why? Because your wallet loosens. Yes, they will prey on your vulnerability to make money, because that is their job. In this mutual deception, both parties participate in the stripper fantasy. One side receives attention and daydreams, and the other receives money. I have zero problem with this. I support people's rights to choose what they want to do with their bodies.

I've been in the software industry long enough that I remember attending conferences where I was one of three females out of hundreds of attendees. Being a female in this industry for so long hasn't always been pleasant. I've been hit on and then mistreated when I didn't respond the way the guy wanted. Many men dismissed me. Others blocked promotions, and many more disliked me for being smarter than them. While I've met hundreds and hundreds of amazing people (mostly men) throughout my career, those few bad apples find their way into almost every dev shop.

Given all of this, I never reported anyone to HR. Instinctively, I knew going to HR was a bad idea. I didn't want to get branded as the woman who caused trouble for men. When I began my career in the 90s, many men believed that introducing women in an all-male environment was bound to cause trouble, and refusing to reinforce the stereotype was a matter of survival.

However, at one particular recent job, the toxicity of the environment was bad enough to qualify as a superfund site. I was regularly condescended to. A female junior developer was told to choose a different career path, because having kids would prevent her from achieving success in Site Reliability Engineering. Yes, this was offensive, incorrect and illegal, but it was par for the course at this company.

In another instance, I was mistreated publicly by our vice president for asking for more resources to complete twice the work with half of the people. The condescension was so blatant and uncomfortable that multiple people (who were not me) reported it to HR. This is how I found myself in the center of an HR war.

Prior to that experience, I considered Human Resources my safety net. If anything spun out of control, I knew I could seek help from the HR department. After all, they wanted to keep employees happy. They issued rules about how employees were to treat each other. They planned celebration events for us and set up prizes to acknowledge people. They regularly sent out messaging to say the people who worked at the company were the real capital. I believed, if I were mistreated to the point where I needed outside help, they would see the situation for what it was and help me.

Boy was I wrong!

I won't get into the nitty gritty details about the fallout. I'll save those for my memoir, but I will tell you that every female I knew at that company was abused in some way, some worse than others. Due to my assertive personality, I received the brunt of the public mistreatment in the development department, though many others were abused in more low-key ways. Needless to say, the leadership team was all white men, and the men getting promoted always somehow managed to be members of the same church. This was the classic good ol' boys club.

People roll their eyes when I bring up the good ol' boys club. That's antiquated behavior, and we're modern people with a modern mindset, right?

I wish.

In the same way that institutional racism thrives in our systems, sexism also thrives. Men, in particular, refuse to address unconscious bias, believing they are open-minded and kind enough to not fall prey to misogyny. Unfortunately, they are lying to themselves. Being kindhearted doesn't prevent you from being a victim of culture. Utahns are raised and continue to live in a highly sexist culture where women cannot hold meaningful office in the dominant religion.

Growing up in Utah in the 70s and 80s, I knew women were expected to stay home, birth children and take care of the house. No matter how many excuses people found for the reasoning, women in the religion in which I was raised have always been treated as servants to the men. Without unconscious bias training and a deep desire to eradicate the inequality in their own minds, it is virtually impossible for men to grow up here and believe women are equals.

This is all to say that, by the time a woman turns to HR, she has likely suffered micro-aggressions daily, been treated like she's hysterical by being assertive and passionate and has had her work and ideas stolen and claimed by men. Ask me how I know.

Unfortunately, HR exists for one purpose in situations like these: to protect the company.

Let me say this another way. If you have been treated in such a way that you may have grounds for a lawsuit, you become enemy #1 to the company. Their image and their money is worth more than you. They are not there to protect you. They are not there to discipline abusers. They are there to protect the company. At all costs.

They will not help you prove equal pay for equal work. They do not want you to have a good reason to sue the company and will therefore do what is necessary to keep you appeased and quiet. They are sleeper snipers, because once you have been labeled a trouble maker, they will wait for the smallest mistake to discipline you. They need this "mistake" of yours in their arsenal in case you get pissed off enough to speak to an attorney. They are trained to put out small fires so they never grow into something bigger. That means, if there is something bigger, you will never see the full picture.

Until I experienced this myself, I believed in the ideals that Human Resource departments espoused, and it wasn't until afterward I realized I'd fallen prey to the stripper thinking I was cute. Of course, HR is going to protect the company. Duh. No way will someone in HR say, "I think you've got a good case here. You might want to talk to an attorney." They will do everything in their power to discount you in case the company ever finds themselves on the opposite side of a court room.

Does this mean there is zero protection for women in the software industry? No, but it might not be the protection you thought. These days, there are other women around, and they also work in a male-dominated field. Go to lunch with them. Become friends. You can also create safe spaces for fellow female devs.

There are also some men who have addressed unconscious bias in themselves. There are men and women who recognize talent in another person, no matter what resides between that person's legs, and there are teams where you can operate safely and be treated like a fellow human.

For each uncomfortable moment I've experienced through the years, there were a thousand laughs. Mutual respect on a development team is rewarding. Yes, I write about the pitfalls, but only as warnings, not stop signs. I've made many mistakes through the years. I'm only telling you where to be careful but live the development dream. Have fun at work. Solve cool puzzles and stay humble.

Just remember. If you ever find yourself on the wrong side of someone at work and think about HR, consider the power dynamics. One side holds all of the power and all of the money, and you are not that side. For all of the good intentions of the people who work in HR, no stellar personality with a good heart can win in a competition against the bottom line. That doesn't make any of them mean or bad people. It makes them people who have a job to do, like strippers.

My Dog Peed on the Ivory Tower

Tami Mandarino — Fri, 06 Oct 2023 20:55:53 +0000

Wikipedia describes an ivory tower as “a metaphorical place—or an atmosphere—where people are happily cut off from the rest of the world in favor of their own pursuits.” As an engineer, I use the term ivory tower to describe a stereotypical coder or architect who cannot or will not accept criticism.

If the guy has become an ivory tower due to a cult of personality, you might hear people excuse his behavior with comments like, “He’s so smart he never has to write down any design decisions. He just keeps them all in his head.”

There are multiple reasons why we don’t keep design decisions in our heads including, but not limited to:

designs of any complexity should be reviewed by others, which is impossible if it’s not documented somewhere;
documentation provides the ability to look back, years later, to decide if the design decision still applies;
and the most common usage, design documents exist so that others can understand it during implementation and maintenance.

Ivory towers are often groups of individuals who have final say on critical decisions, decisions that have ripple effects for years, that don’t seek out or listen to other people’s input. They are the corporate-appointed monarchs of development.

Ivory towers house the echo chamber for the good ol’ boys club and are usually led by the one guy who, with a smile on his face, will tell you to sit down, because the adults have made the decision. Or he’ll sneer and offer a satisfied smirk afterward.

An ivory tower might just be one toxic person that can’t take feedback and can’t believe you would have the audacity to give it. In fact, toxicity in teams is usually driven by a single individual. Most people strive to do good work, be kind to their peers and go home at the end of the day, but ivory towers are narcissists who feed on ego. They only want to hear praise.

This is the reality in the vast majority of dev shops. Usually it’s just one person or one group that behaves this way, but it puts strain on other teams. Why? If it’s the corporate-appointed monarch ivory tower making decisions without input, devs get irritated and angry. They want input into what they will be doing for the next year of their lives at work. They may have experience relevant to the technology decision and can give an honest answer about the trade-offs involved. They might know of a better tool. Nobody wants to repeat past mistakes.

I am always awed when I discover the depth of knowledge embedded in coworkers all around me, and the more I see, the more I accept how much I need their input to be successful. For every person who is willing to blog about the cool things they learn, there are a thousand others who have deeper knowledge that never write a single word, and sometimes, they can be found sitting right next to you.

Since ivory towers can be categorized under toxic work culture, they should be dismantled, but how?

Well, if I had the silver bullet to remedy the situation, I’d be in a different place in my life, but I have learned some effective tools to shift work dynamics. All ivory towers share the common trait of being incapable of taking feedback, and to be honest, I get it. Criticism is terrifying. Being told you haven’t made the best decision is hard to hear. If your self-esteem is tied to work, learning you might not be as good as you think you are can have ripple effects in other parts of your life.

I’m an author, and after writing my first novel, I had several people (who love me) fawn over the novel. In my ivory tower of self-congratulation, I shared my masterpiece far and wide until one friend read it and articulated its flaws. I was devastated and hurt. How could someone tell me my first novel wasn’t perfect? But . . . but . . . my mom loved it! After a bit of reflection, of course, I quieted my bruised pride and accepted the truth. She was right. I realized that accepting feedback was a crucial path I needed to take in order to get better. I forced myself to disconnect from my writing and accepted there was a lot about writing I didn’t know. Years later, after completing several publishable novels, I circled back to that friend and thanked her profusely for her honesty.

Accepting feedback gracefully can be hard, but it gets easier with practice. A lot easier. If you accept that your efforts cannot and will not ever be perfect, but the quality of your efforts can be improved by learning from others, the ego quiets down.

And therein lies the answer. Foster a culture of accountability, and divorce yourself from your work product. Ask your peers to go hard on your pull requests. If you’re early in your career, seek out mentors. Don’t encourage or participate in a culture of rubber stamping other people’s code. If you don’t have any suggestions for a pull request, ask questions. Show that you’re teachable. When you make a design decision, document it and ask for feedback, even if you only do it on a whiteboard. Be willing to be criticized.

Some of us haven’t figured out how to accept feedback, and there is no shame in that. I was one of those people, and I learned the embarrassing way, so I will share my methodology in the hope that it will help someone else avoid defensiveness and temper tantrums.

First I assume the person giving me feedback is correct, and I immediately attempt a paradigm shift in my head to see the situation from that person’s perspective. When I do this, questions bubble up. Can I get more detail? Since all decisions have trade-offs, what’s to be gained by changing the decision and what might be lost? Why did I think it was a good idea to do it that way? Is this a hole in my knowledge? Where can I learn more about this so I don’t make the mistake again?

Sometimes, I can’t force myself down the road to agreement, and when that happens, I request time to chew on it. While I’m processing, I dig for the good in what I’ve been told. Almost all of the time, I beeline to google to see what the rest of the world says about the problem. How have other people solved it? What pitfalls lie down the two roads?

Sometimes the person giving me feedback is correct, and when that happens, I’m grateful I wasn’t defensive. I usually shoot the person a note to thank them for teaching me something.

Sometimes the person is wrong, and I may send them the results of my research and ask for more discussion, or I may ignore it, depending on the other person's personality. Most of the time, however, we’re both partially right and partially wrong. The world of engineering and design is rife with trade-offs and few things are all one way or all the other. What may be right in one architecture might not be the best choice for a different architecture. What may have been right a couple of years ago might not be considered correct today. Give yourself and other people grace to make mistakes.

If someone has the courage to provide you real feedback, recognize what a Herculean emotional feat they made on your behalf. Since the inability to take feedback is so common, they know they risk upsetting you. Remember they are subconsciously making a decision about whether they’re going to go out of their way to help prevent your faceplant in the future.

Finally, when someone is correct, acknowledge them. It doesn’t have to be cheesy. It can be, “Thanks! I learned something new today.”

Funny things happen when you have the courage to be vulnerable. Stronger bonds form between teammates, and a culture of trust and excellence begins. Everyone gets better at everything which becomes a multiplier for productivity.

Do I expect an ivory tower to come tumbling down because I sought feedback on work products? No. That’s not how narcissism work, but actively requesting critiques changes the way other people think about feedback. Vulnerability gets normalized and more people jump into the fire asking for feedback, which results in all around better collaboration and an increase in the quality of your code. Meanwhile you grow together and rack up wins.

Later, as you glide past the ivory tower on your road to success, take a moment to look back and reflect on how far you’ve come and why not? If you’re so inclined, let your dog take a leak.