Iteration is important.
I’ll say it again. Iteration is important.
It’s something I talk about regularly because, well, it’s worth repeating.
Software is never done. Requirements change over time, your understanding of the business problem will change, and your application will be enhanced as you add new features. As you build more, you’ll revisit existing functionality and make it better. You’ll realize this isn’t actually what the customer wants and tailor a better UX.
You’ll get into a new tech stack and want to refactor your solution. …
I recently got out of my first death march.
For the uninitiated, a death march is a term used in the software industry to describe a development project that is one of the following:
My death march was the prolonged-period-of-overwork kind. Not fun.
It went on for about a month, then tapered off and things got back to normal.
But as a leader, I reflected back at the past month and tried to get a look at the pros and cons: What…
If you’ve recently made the move from developer to solutions architect, congratulations! Welcome to the technical world of system design.
A misconception I see regularly with new SAs is that they think their job is solely to come up with a way to solve a business problem. While that is fundamentally correct, there’s a whole lot more to it than that.
While a race car driver’s job is to drive a car around a track, their objective is to do it faster than everyone else. …
If you’ve worked with AWS in any sort of capacity, you’ve probably learned they have a unique way of doing things. They start off meetings reading documents in silence, they begin new projects by working backward, and no matter what they do, they drive their leadership principles… hard.
There’s a reason Amazon basically runs the world. Their way of doing things works.
Among the many artifacts they produce to help companies build best-in-class software are their general design principles. If you’ve ever been through an AWS Well-Architected review, you know all about them in excruciating detail (in a good way).
Last week, I was giving an introductory class to my company’s technical support team on a new product we’ve been building.
The new product is completely different than anything else we’ve built before. The tech stack, programming languages, methods of deployment, you name it — it’s different.
As I was walking through the structure of our repositories, the support engineers asked me, “Are there any diagrams of what this looks like when it’s deployed?”
I thought about the question for a minute. I have about 30 different diagrams describing the different architectural pieces of the app but not too many…
Have you ever been in a meeting where someone is trying to explain how a software system works?
I was having a conversation with a relatively new solutions architect who was trying to describe a system they had come up with. It had about eight different components to it and they all interacted with each other in multiple ways.
They were explaining the solution using hand gestures and a lot of “and this piece communicates with this one by…”
I understood the words coming out of their mouth, but they didn’t make sense strung together.
Words get lost when explaining…
I was sitting on a call the other day.
We were going through a list of requirements for a project my team has been working on. I had called the meeting to let stakeholders know development was going to slow down.
The senior architect on my team had left in the middle of the project. So I, of course, had to inform the people who care that the date was going to slip.
The answer I received was “That is a hard deadline. We still need all the work by that date.”
So I still had to get the same…
I had an interesting dream last night.
I was working remotely in some random house and conducting a sprint review. The primary stakeholder was also in this random house, but working remotely from a different room. The sprint review was carrying along fine, business as usual.
Out of nowhere, a tornado rips through the house, leaving the primary stakeholder and I hurt and freaking out a little bit.
But the sprint review carried on. Somebody else picked up where I left off in the demo and another person picked up raising concerns for the primary stakeholder.
I woke up shortly…
Serverless is great. There, I said it.
At this point, I’m not sure many people would argue with me on that, but to each their own.
Serverless provides us with the luxury of fast compute in the cloud without having to worry about machines or state. Pretty awesome.
But since we don’t have to worry about machines or state, a handful of problems that we didn’t have before have presented themselves. Things like monitoring your app become more difficult. You also have all the difficulties of distributed computing thrown into the mix.
But what about a static IP? There…
The first time somebody asked me that question in a sprint review, I had no idea what to say. I was a junior developer at the time and the question destroyed me.
I stammered. I fidgeted. I looked over to my boss for help. I was truly at a loss for words.
I had just finished demoing my first project from start to finish. I was proud to say that I did this.
But when a stakeholder asked me, “So what?” I didn’t know what to say.
I knew how my project worked. That was it. I didn’t…
I work in the cloud with a strong focus on serverless and API lifecycle. Pushing the limits on API design, standardization, and automation.