3MI lab

Home
Croatia
Zagreb
3MI lab

Contact information, map and directions, contact form, opening hours, services, ratings, photos, videos and announcements from 3MI lab, Computer Company, Ulica Majstora Radonje 10, Zagreb.

29/09/2026

In early computing, programs were stored on punched paper tape or cards. Corrections could be punched onto a separate piece of tape and added to the original program.

A 1964 DEC manual even described successful corrections being produced as “loadable patch tape.”

Today, patches travel through automated pipelines instead of paper but their purpose remains familiar: making a focused change without replacing the entire system.

The technology has evolved dramatically. The need to change software carefully has not.

23/09/2026

The highest-risk dependency in a long-lived software system may not be a library or an external service. It may be the one person who knows why everything works the way it does.

Specialist knowledge is valuable. But when critical context exists only in someone’s memory, routine maintenance becomes slower, incidents become harder to resolve, and every handover introduces unnecessary risk.

Maintainability depends on making knowledge part of the delivery process: record the reasoning behind important architectural decisions; use code reviews to share context, not only to find defects; keep operational runbooks current and usable; assign shared ownership of critical components; document integration behaviour and recovery procedures; include knowledge transfer in every significant change.

The goal is not exhaustive documentation. It is to preserve the information another capable person would need to understand, operate, and change the system safely.

Strong teams still have specialists. They simply make sure specialist knowledge strengthens the whole organization instead of becoming a single point of failure.

16/09/2026

Enterprise deployments often include more than application code: configuration changes, database migrations, integration settings, infrastructure updates, and new operational dependencies. Each part can succeed technically while the complete business flow still fails.

That is why a reliable release process should verify that:

* the expected version and configuration are active;
* database changes completed correctly;
* dependent integrations can communicate;
* critical business flows pass post-deployment checks;
* logs, metrics, and alerts provide the expected visibility;

CI/CD makes delivery repeatable, but automation should follow the full definition of a successful release - not stop at “deployment completed.”

The release is complete when the team has evidence that the change is running, observable, and safe to continue operating.

10/09/2026

A slow application does not always need a bigger server. Sometimes more capacity is necessary.

But if the underlying problem is an inefficient access pattern, additional resources may only make that problem more expensive.

A useful diagnosis looks beyond average CPU or memory usage. It examines:

* query ex*****on plans and the volume of data being read;
* whether indexes match real access patterns;
* long transactions, blocking, and lock contention;
* repeated requests for the same information;
* data growth, retention, and archiving rules;

The business symptom may be “the application is slow,” while the technical cause is one query that scans far more data than necessary or one transaction that blocks several others.

Performance work should therefore begin with evidence. Measure the behaviour, locate the constraint, and then decide whether the correct response is a query change, a data-model adjustment, an architectural change, or additional capacity.

Scaling is most effective when the team knows exactly what it is scaling.

08/09/2026

The size of a legacy application does not tell us where modernization should begin.

A smaller component may carry the greatest operational risk because it supports a critical workflow, depends on an obsolete technology, or has become difficult to change safely. A larger component may be stable and require no immediate intervention.

Before choosing between replacement, refactoring, or gradual extraction, teams need to understand:

* which business processes are truly critical;
* where failures create the greatest impact;
* which integrations constrain change;
* where knowledge or support is concentrated in too few people;
* which components can be isolated without disrupting daily operations.

This creates a modernization sequence based on risk and business value - not on the visual shape of the current architecture.

For long-lived enterprise systems, controlled evolution is often more responsible than a single large transformation.

02/09/2026

The happy path is usually easy to describe: a request is submitted, approved, processed, and completed.

Enterprise software becomes complex when the real questions begin.

What happens if the same request arrives twice? If one approval is missing? If an external system is temporarily unavailable? If one step succeeds but the next one fails?

In high-volume, integrated environments, these are not rare edge cases. They are part of everyday operations. That is why business analysis should define more than the ideal workflow. It should also clarify:

* who owns each exception;
* what the user sees;
* which actions can be retried safely;
* when manual intervention is required;
* which information must remain available for audit and support.

When exception paths are considered early, architecture and development teams can design predictable recovery instead of adding it under production pressure.

A complete requirement does not only describe how a process succeeds. It also explains how the process continues when something does not go as planned.

27/08/2026

An API is often described as a technical connection between systems.

But it is also a promise about how those systems will communicate.

What information will be available?
In what format?
How will changes be introduced?
What happens when a request fails?

When these expectations are unclear, even a small change in one system can create problems elsewhere.

Well-designed APIs require consistency, predictable behaviour and clear ownership not only working endpoints.

Because successful integrations depend just as much on good agreements as they do on good code.

20/08/2026

CAPTCHA is not simply a made-up technology term.

It stands for:

“Completely Automated Public Turing test to tell Computers and Humans Apart.”

The interesting contradiction is that a computer automatically creates and evaluates a test intended to determine whether the user is a computer.

CAPTCHAs help protect websites from automated abuse, spam and malicious bot activity. However, they can also introduce friction and accessibility problems for real users.

Security controls have to stop unwanted activity without making ordinary tasks unnecessarily difficult.

Because a system can be secure and still provide a poor experience.

18/08/2026

Deleting data sounds simple.

Select a record. Click Delete. Confirm.

But behind that one action, the system may need to manage relationships between records, update reports, preserve an audit trail or keep the data recoverable for a defined period.

That is why deletion should never be designed as an afterthought.

A well-designed deletion process protects users from accidental loss, keeps connected information consistent and makes the consequences of every action clear.

Because creating data is usually one event.

Deleting it affects everything that came after it.

12/08/2026

Automation can save time, reduce repetitive work and lower the risk of human error.

But automating a poorly designed process does not necessarily improve it.

Sometimes it only allows the same inefficiency to happen faster and at a larger scale.

Before introducing automation, it is worth asking:

- Is every step still necessary?
- Where do delays actually occur?
- Which decisions require human judgment?
- What should happen when an exception appears?

The first step is not always to automate the process.

Sometimes the first step is to simplify it.

Address

Ulica Majstora Radonje 10
Zagreb
10000

Website

http://www.3mi-lab.com/

Alerts

Be the first to know and let us send you an email when 3MI lab posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to 3MI lab: