custom software development Tag

hybrid; stack of different sliced fruit 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.

user requirements specifications document paper work vector 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?  

communication 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?

Monolith; Monolithic Rollout of Legacy System Conversion 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.

software automation Can software replace my job? It's a concern with roots going back centuries to the arrival of the first automated power looms in 18th-century England, continuing into more modern times with the large claw-like robots that build automobiles. Today it seems there are hundreds of websites making their living pushing clickbait headlines describing the perils of the coming Robopocalypse of software automation replacing human workers, and I often see those fears bubbling to the surface when working with clients. Fortunately, in my experience, those fears are often overblown, and I'm not alone in thinking so. Wired's James Surowieck agrees that we have nothing to fear.   The automation jitters usually start to come out during discovery. I talk with clients to clarify the business logic, workflow rules, or other automated features, and I'll use the term "robot" to describe the software we're building. After all, "if I can't tell the robot what to do, how will it know how what to do?" It's somewhere around here when we're asking somebody to explain their whole job function that somebody on the client's team will mutter, half-jokingly, "So I guess I better start looking for another job, huh?" It's not hard to understand where that thought is coming from. After all, if we can completely strip away the human layer and turn their job into a series of rote, mechanical steps, what role is left for them? I quickly try to assuage their fears.

DISCLAIMER - this article applies to mainly to Organizations without business analysts and programmers on staff. A few years ago, we were asked to quote a small automation for an existing, repeat client. They wanted help streamlining a spreadsheet-based process that took about 1/2 day of a high-level employee's time each week.

Client: Can you help us save some time by writing some Excel macros?

Susco: Of course we can develop some Excel macros for you. But first, why do you need them?


software managementLet me take you back to the year 2011.  This was a big year for us, as Susco had made a big name for itself as one of the first movers in mobile app development studios in the State of Louisiana. We were growing revenue at 50% per year and collecting awards like they were going out of style. At the time I was a babe at 33, not a grey haired 39 year old –  so needless to say, the success started going to my head. I thought of myself as being very emotionally intelligent with how I dealt with people, but it’s very easy when growing a company to do a great job focusing on the way you treat your clients and referral sources but not apply the same effort with your staff.  This blind-spot almost cost me one of my best employees at the time.  In the interest of protecting the innocent, I’ll refer to them as “Bob”.  So, here we go…

custom software We get this question a lot from business owners in the middle of a growth phase. Often, they are already using systems for accounting and CRM (Customer Relationship Management), and they are not sure what processes could be improved, and if there is a business case to improve them. Over the years, we've identified a number of clear indicators that it's time to invest in technology. This can be in the form of implementing a pre-existing Software-as-a-Service (SaaS), implementing a platform solution, or developing a custom software solution. We'll elaborate in an upcoming post on which of the 3 solutions is the right fit for you, but for now let's focus on the "smell test" of determining if there is a need. Some are obvious, while others are more subtle.