Tag: software engineering

Form follows fiasco

~ Oleg Dulin

Why software architects should stick with their projects Last weekend, I took my daughter to an antique bookstore/coffee house where we came upon a book called "Form Follows Fiasco: Why Modern Architecture Hasn't Worked." This book is not about software architecture. It's about actual architecture, which involves buildings that might collapse if not built right. … Continue reading Form follows fiasco

Software Engineering is here to stay

~ Oleg Dulin

I counter the dramatic assertion that developer jobs are on the brink of obsolescence. I distinguish the roles of coders, who may face obsolescence due to their narrow focus on translating specifications into code, and software engineers, whose broad skill set in solving complex problems and innovating ensures their continued relevance. I argue that artificial intelligence and large language models augment rather than replace the human intellect, emphasizing that while app development and deployment methods may evolve, the necessity for software system maintenance and the efficiency of programming languages as a form of shorthand will keep developer roles indispensable. I argue that, despite technological advancements changing the landscape of app development, the core importance of the software engineer's role remains unchanged.

Comparing AWS SQS, SNS, and Kinesis: A Technical Breakdown for Enterprise Developers

~ Oleg Dulin

Queuing is a critical component of software architecture, and choosing the right system for your cloud-native enterprise application is crucial. In this blog post, we'll compare Amazon Simple Queue Service(SQS), Amazon Simple Notification Service (SNS), and Amazon Kinesis, exploring their strengths and weaknesses to help you determine which queuing system is best suited for your use case. 

Stop Shakespearizing

~ Oleg Dulin

Ultimately, you must know your project, your needs, yourself, your skills, and your team. Only you are responsible for your project. So trust your instincts, fellow architect, and don't Shakespearize 🙂

Why don’t they tell you that in the instructions?

~ Oleg Dulin

The nature of our jobs as software engineers is such that we must deal with externalities. Hardware will crash. Services will auto-scale up and down. Garbage collection will occur. Humans will make mistakes and use our software in ways we did not anticipate. Someone will write configuration instructions for you on how to setup your dev environment, and they might not apply perfectly to your setup.

Monolithic repository vs a monolith

~ Oleg Dulin

Monorepo makes sense under some circumstances and makes no sense under others. A set of related features with related code, similar security, performance, and scalability profiles belong in a single deployable service. Services that are functionally related and have a closely aligned release cycle belong to the same monorepo.

Java is no longer relevant

~ Oleg Dulin

Though Java was my primary way of earning a living from about 1997 to 2015, it has long outlived the problems it solved. Java’s issues are being solved now by modern tools like Docker. Except for a few niche use cases, I no longer use Java for my projects.

Tools of the craft

~ Oleg Dulin

Developers should feel empowered to configure their environment and development tools to their liking and contribute to the shared team standard. They should know the libraries they picked and why they picked them. They should be able to articulate why they like one programming language over another. As part of their job, each developer should be able to state clearly and in actionable terms how they’d like to work.