Strategy

Sometimes software systems are just too large for a single team with the generally-accepted “7 plus or minus 2” size to handle.

Everything is changing—and nothing is changing about that anytime soon. Now more than ever, application modernization and the agility it brings prepares companies for potential disruptions and enables them to quickly take advantage of new opportunities.

Application modernization is a big decision. How do you know when it’s time to update, and how do you get started?

Like so many businesses, MercuryWorks has put great energy into grappling with the impacts of COVID-19 shelter-in-place/stay-at-home orders. We needed to quickly and smoothly shift all employees to working from home. This brought work lifestyle changes to the forefront. This post is intended to highlight some of the moves, tools and techniques we implemented to work completely remotely.

Mercury New Media has transitioned to a new name – we are now MercuryWorks!

If you are familiar with professional service companies specializing in Web Development or Digital Applications, then you are undoubtedly aware of the pressures and day-to-day struggles that come with meeting the demands of clients. Contrary to social folklore, the customer is not ALWAYS right, however they should always be HEARD. Instead of arguing and potentially losing a client, here are some helpful actions meant to prevent you or your company from constantly battling over the same ground.

Design is incredibly subjective and each person has their own opinions and interpretations. To ensure your vision is realized you can implement interface prototyping to visually display thousands of words worth of design and development requirements regarding how a system should both look and behave.

The rising demand for getting a Minimal Viable Product (MVP) to the market as quickly as possible has highlighted the criticality of Validated Learning within the Software Development Lifecycle (SDLC.) Throughout the remainder of this blog post, we’re going to apply 2 of the 5 principles in Eric Ries’ book “The Lean Startup”: (1) Validated Learning and (2) Build-Measure-Learn. Let’s consider our first scenario.

Hopefully by now it has become apparent that it is nearly impossible to avoid accumulating technical debt while building software and systems. The question is not so much whether or not you are going to take on technical debt but rather how quickly, what kind and what you are going to do about it in the long term.

Naïve/Reckless/Unintentional Technical Debt aka Mess Naïve Debt, Reckless Debt and Unintentional debt are different names for a form of technical debt that accrues due to irresponsible behavior or immature practices on the part of the people involved. In our experience it is very rare to find this kind of technical debt stemming from conscious irresponsible development behavior. However, it is very common to find this kind of debt originating from developers not trained in current and robust development techniques, when little architectural planning has taken place or the toolchain the development team uses is immature.