Architectural compromises
Sep 16, 2024
in •
ATAM
•
CBAM
•
COST
•
COST BENEFIT
•
COST BENEFIT ANALYSIS METHOD
•
INSTITUTE
•
ITALIAN
•
ITALY
•
METHOD
•
POLAND
•
SWEDEN
•
SWEDISH
•
VAZA
vaza
sweden
poland
king
time
soa
atam
architecture tradeoff
benefit analysis metod
sei
software engineering institute
architecture
software
ship
ships
swedish king
italy
benefit analysis method
cbam
2 min read
An architecture cannot accomplish high security, high availability, high abstraction, and high performance all at once. All that software architects need to do is know, understand, and relate one real narrative to their peers and clients. I am speaking of Vaza’s history.
In 1620, there was a war between Sweden and Poland. An attempt was made to bring this expensive war to an early end by the Swedish King by ordering the construction of a galleon known as the vase. The ship was not like the others. It was unlike any other ship of the time in its features. It had to be longer than sixty meters in order to safely convey 300 men at a time to Poland while also carrying 64 weapons on two battery decks.
...
➦ Simplicity is achieved through reduction
Sep 13, 2024
stefan
extra
code
line
algorithm
variables
start
2 min read
“Do it again…” my boss said, firmly holding down the Delete key with his finger. With familiar sorrow, I watched the screen where my code was irrevocably disappearing, line by line.
My boss Stefan wasn’t particularly eloquent, but he could spot bad code at first glance. And he knew exactly what to do with it. I took that job as someone learning programming – full of energy and enthusiasm, but with no idea how to write code.
I was under the terrible delusion that any problems could be solved by adding another variable in the appropriate place or by adding another line of code. On bad days, my code would degrade—its logic wouldn’t improve, and moreover, it would become bulkier, more complex, and more unstable.
...
➦ Programming paradigms
Sep 07, 2024
in •
ADA
•
C
•
C LANGUAGE
•
C++
•
FORTRAN
•
HASKELL
•
PASCAL
•
PROLOG
programming
pascal
fortran
c
c++
ada
haskell
prolog
language
programmer
languages
difficulties
paradigms
3 min read
Psychology of Programming: It has long been known that a programmer’s professionalism directly depends on the number of different programming paradigms they master—not just having heard of them and knowing about them, but being able to actually use them in their work.
Every programmer starts with some one language. This language has an the predominant influence on how a programmer sees software. But no matter how long a programmer has worked with this language, if they only work with it, they will only know this language. The thinking of a programmer who knows only one language is limited to the capabilities of that language.
A programmer learning a second language will encounter difficulties, especially if the computational model of the second language differs from the first.
...
➦ Interfaces
Sep 06, 2024
api
interface
interfaces
users
use
user
3 min read
One of the most common tasks in software development is interface specification. Interfaces exist at the highest level of abstraction (user interfaces), at the lowest level (function interfaces), and at intermediate levels (class interfaces, libraries, etc.). Regardless of what you are doing—aligning with end users on their future interaction with the system, collaborating with developers to develop the API specification, or declaring private class functions—interface design is an important part of your job. If you handle it well, using your interfaces will be a pure pleasure, and user productivity will increase. If you handle the task poorly, your interfaces will become a source of frustration and errors.
Good interfaces possess the following properties:
They are easy to use correctly. Users of a well-designed interface almost always use it correctly because that is the path of least resistance for that interface.
...
➦ Improve the code by removing it
Aug 22, 2024
advice
yagni
system
code
requirements
client
tip
2 min read
Less is more. It’s a clichéd short maxim, but sometimes it’s really true.
Over the past few weeks, among the improvements I made to our code was the removal of some of its fragments.
We were developing the project following the principles of extreme programming, including YAGNI (You Aren’t Gonna Need It). But human nature is imperfect, and in some places we made mistakes.
I noticed that our product took an unjustifiably long time to perform certain tasks—simple tasks that should have been completed almost instantly. This was all because we overcomplicated their implementation—with all sorts of trinkets and bows that were actually unnecessary but seemed useful at some point.
So, I simplified the code, improved the product’s performance, and reduced the overall code entropy, all thanks to removing unnecessary functions from the project code.
...
➦ Communication is the king, clarity and leadership are its loyal servants
Aug 08, 2024
in •
INDIA
india
visio
act
developers
software
clarity
project
leadership
3 min read
Psychology in IT manifests in everything. Every person has their own base tendencies to dominate. Remember that famous experiment where a group of people was divided into prisoners and guards? Or India with its castes? Well, IT is just like India.
Too often, software architects dwell in ivory towers, sending down specifications to developers and imposing technologies and directions on them. This often leads to conflicts, which are quickly followed by a “popular uprising.” As a result, a software product emerges that has nothing to do with the original requirements. Every software architect should be able to explain the goals and objectives of the software project to their colleagues. The keys to effective communication are clarity and leadership.
Clarity characterizes the communication process. No one in your group will become read a 100-page document justifying your architectural decisions.
...
➦ Read the code
Aug 08, 2024
start
code
reading
skills
today
projects
2 min read
We, programmers, are strange creatures. We love writing code. But when it comes to reading code, we usually shy away from it. After all, writing code is much more exciting, and reading code is difficult—sometimes almost impossible. Especially hard is reading code written by others. Not always because it is poorly written, but because another person thinks and solves problems differently than you do. Have you ever thought that reading someone else’s code can help improve your own code?
The next time you read some code, stop and think. Is it hard to read or easy? If it’s hard, why? Is it poorly formatted? Is the naming system inconsistent or illogical? Are multiple tasks mixed in one piece of code? Perhaps the chosen language makes the code difficult to read.
...
➦ Know how to use command line utilities
Jul 21, 2024
microsoft
eclipse
gui
ide
tools
command-line
use
line
3 min read
Today, many software development tools are delivered as integrated development environments (IDEs). Besides the two popular examples – Visual Studio from Microsoft and Eclipse from the open-source community – there are many others. A lot can be said in favor of IDEs. They are easy to use and they free the programmer from the need to delve into many minor details, including the build process.
However, ease of use has its downside. A tool is usually easy to use when it makes decisions for the programmer and automatically does a large amount of work behind the scenes. Therefore, if you only use an IDE as your programming environment, it is quite possible that you will never fully understand what your tools are actually doing.
...
➦ To do something hastily and run away is a crime
Jul 20, 2024
john
run
time
tests
code
work
3 min read
It’s getting close to evening. The team is diligently working on the new functionality planned for the current iteration; it seems even the air in the room is pulsing with the rhythm of work. However, John is a bit in a hurry: he has a date waiting for him. However, he manages to finish writing his part of the code, compiles it, registers it in the version control system – and hastily leaves. A few minutes later, the “red light” comes on: the application build is broken. John didn’t have time for automated tests, so he went with the “hack and run” principle, which caused the entire team’s work to come to a halt.
The situation has changed – the work rhythm has been disrupted.
...
➦ Write code as if you will be maintaining it for the rest of your life
Jul 19, 2024
code
start
career
life
rest
2 min read
You can ask 100 different people what any programmer should know and be able to do, and get 100 different answers. This can be both overwhelming and frightening. All advice is good, all principles are sound, all stories are convincing, but where to start? And, more importantly, once you start applying best practices, how do you maintain the right level and make them an integral part of your programming practice?
I think the answer lies in your mindset or simply in your approach. If you are indifferent to your fellow developers, testers, managers, sales and marketing staff, as well as end users, you will not feel the urge to, for example, conduct test-driven development or write clear comments in the code. I think there is a simple way to change your attitude and develop a desire to release products of the highest quality:
...
➦ 
