We see it all the time: a company has a long-established software system that's either fully custom or has been customized to fit just right. It's perfect, or as nearly perfect as software can be. And then the company grows. It evolves with the changing marketplace. Little by little, that perfect fit starts to pinch here and sag there. You know you'll need to do something about that legacy software eventually, but not now. When does "eventually" become "now"? How can you tell when it's time to overhaul your legacy system?
If you carry inventory, you need efficient, effective inventory management software. Since it's such a critical part of your infrastructure, it's important to select the right tool for your needs. Should you choose a commercial off-the-shelf (COTS) package, or do you need custom inventory management software?
For any organization led by a board of directors, communication is vital. Board members need a great deal of well-organized information in order to perform their duties. Staff members have traditionally prepared board books and meeting documents, assembling and organizing possibly hundreds of documents for each meeting. While it's possible to cobble together a solution using existing software like project management systems and online document sharing tools, these DIY systems don't offer the efficiency or features of a dedicated board of directors portal. These portals provide several features to help boards work efficiently and effectively.
So you want to build a mobile app. Should you choose native or hybrid mobile application development? Each choice has advantages depending on your projected use and time to market.
What is a hybrid mobile application?
Mobile apps generally fall into two categories, native and cross-platform or "hybrid". A native mobile application is just what it sounds like: it uses the SDK (Software Development Kit) and hardware features specific to a particular mobile operating system. Hybrid mobile applications also fall into two general categories, hybrid HTML5 apps and native cross-platform apps.
Writing software requirements should be easy, right? Right? Of course we know exactly what we need and can tell you exactly what the software should do.
Unfortunately, it's not always so easy. Writing software requirements well takes detailed, deep thought about business requirements. It also takes clear communication between the people who will use the software and the people who will write it.
It isn't always easy to translate between business-speak or industry-speak and developer-speak. This can cause costly confusion. Fortunately, there is a language called Gherkin to help bridge the gap.
So what makes a good set of software requirements, and how can we develop those requirements?
Is your software development team listening to you? Good project communication helps prevent costly rework and ensures that product owners and development teams understand each other.
We don't speak the same language, even if we're both speaking English.
We all know that feeling of frustration when we're trying to communicate and just not getting through. I spelled it all out in careful detail, and all I see are blank looks. Were they even paying attention? This is an important project! Is my software development team listening to me at all?
You may have heard software developers and project managers talk about "technical debt". This term has been around since the 1990s and is growing in popularity. But what is technical debt and why do people keep talking about it?
Legacy system conversion projects are always challenging. Rollout strategy can make a huge difference in successful user adoption and overall project success.
Only when I began writing them down did I realize that I had recurring dreams. I had believed that my dreams were largely random and varied, but instead I learned that I had many frequently recurring themes. Similarly, the process of writing down my thoughts on software development has shown me that there are also recurring themes.
One of these themes is the impact of rollout methodology on a project's success. More specifically, rollouts of legacy system conversion projects. Rollouts of brand new systems into an organization are typically less painful, as you are often automating a paper process, or inventing a new process that improves productivity. However, legacy system conversions are almost always painful, as there are many processes that have emerged around this system. People have developed a form of muscle-memory with the old system that even they themselves scarcely understand.
We have successfully replaced dozens of legacy systems where everyone was happy and all was good with the world. But it's not those projects I want to talk about. I am going to talk about the projects where things went awry, because I don't want to make the same mistakes again. Hopefully, these words will also help the reader to avoid similar problems in their projects.
I'm not sure if there's any consensus on the definition of an emergent workflow. It's a term that I use to describe a pattern I have witnessed in business software. To me, an emergent workflow is a workflow that was not designed explicitly into a piece of software, but slowly evolved via users' usage of the system, and the development of conventions to support workflows as they develop. If you have ever developed a piece of business software that manages any form of workflow, and that software has been in production for more than a year, you can be certain that there is an emergent workflow within that software – whether you realize it or not.