Emerging Market Software Blog

Why does it take so long to build software?

published on 2021/01/27

Why does it take so long to build software? We hear variations of this question frequently: Why is building software so expensive? Why is my team delivering software so slowly? Why am I perpetually behind schedule with my software?

There is a good reason we hear these questions over and over. Businesses need more and more custom software every day in order to stay competitive, and yet it feels like as time passes the speed at which we are delivering software is stagnating, or worse, getting slower.

I’d like to talk to you all about why this is, but in order to explore the topic, I need to introduce you to a topic that is near and dear to my heart: Essential complexity and accidental complexity.

Simple Thread

Whenever someone approaches us to build a software, our first set of questions are about figuring out if it is necessary. Building quality software takes time;then you have to maintain it to keep up with the changes in your business process. The great thing is that once you integrate it with your business process, you will see a massive improvement on your efficiency and effectiness because the readily available accurate information.

Every company is becoming a technology company. It is important to sustainably invest on your software infrastructure. Slow and steady is much more preferable than rushing and unsustainable.

Welcome 2021

published on 2021/01/26

What a year 2020 was and it was not over yet.

We have been working remotely since middle of March 2020 and we are not returning to our office anytime soon.

We are grateful that we got through 2020, that our loved ones are safe and that the situation in Egypt, although dire, isn't as bad as many other countries.

As a company 2020 was our busiest year. We were working on a lot of new projects which we are looking forward to deliver this year.

pg_auto_failover now supports multiple standby architecure

published on 2020/10/08

In the pictured architecture, pg_auto_failover implements Business Continuity and data availability by implementing a single PostgreSQL service using multiple with automated failover and data redundancy. Even after losing any Postgres node in a production system, this architecture maintains two copies of the data on two different nodes. pg_auto_failover

This makes making high scalability configuration for PostgreSQL database much easier.

.NET 5.0 now has go live license

published on 2020/09/15

Today, we are shipping .NET 5.0 Release Candidate 1 (RC1). It is a near-final release of .NET 5.0, and the first of two RCs before the official release in November. RC1 is a “go live” release; you are supported using it in production. At this point, we’re looking for reports of any remaining critical bugs that should be fixed before the final release. We need your feedback to get .NET 5.0 across the finish line. Microsoft

If you are a client of SilverKey and currently have an actively deveoped project with us, your project will be upgraded to .NET 5.0 immediately. If your project with us was deployed with ASP.NET Core 3.1, we will upgrade your project to .NET 5 once it is released.

A story of software implementation failure out of Denmark

Large software implementations are very risky. Proceeed with cautions.
published on 2020/08/01

For three years, a dour anesthesiologist and computer architect named Gert Galster tunneled in the electronic guts of Epic Systems, trying to convert the premier U.S. digital health software into a workable hospital management system for Copenhagen and the surrounding region.

It nearly drove him mad.

After Galster and his colleagues had done what they could, 45,000 clinicians in eastern Denmark were plunged into the Epic system. Like the U.S. Department of Veterans Affairs, the Danes had expected that tech from a big IT vendor would make it easier for doctors in an excellent health care system to work, share patient information and keep tabs on costs. But the Danish experience produced results that varied from frustrating to disastrous — a sobering lesson for the VA, which recently began a transition involving another big vendor.


There is a lot of things that can be learned from massive IT failures. It is critical that decision makers are informed by the risks of such implementation and not completely bamboozled by vendors marketing and sales pitch. IT implementation changes dynamic of day to day operation of organizations. It is important that wide range of people are consulted including the potential users. A "ready" software is almost never is.