Software Project Rescue
The agony of a struggling software project
Most software projects, particularly in application development, are planned on a "least time" basis, without taking maintainance into account. This is an expensive preposition, however, because industry-wide, more than 75% of effort is spent on maintainance. [1]
When projects are in crisis, software organizations often look to hiring a "hero" developer who can bring the project back on track. Yet, such heros are hard to find and even harder to keep -- as you need to find a person who:
- is skilled at maintainance and reengineering
- ideally is expert with the programming languages, frameworks and other tools used; you may need to settle for someone who can (hopefully) become expert quickly
- is able to understand the existing code well enough to be able to make both large and small changes, as well as tell the difference between the two
- gets along with your existing team
Such a person is expensive to hire, yet, is likely to make slow progress because of the difficulty of the task. No matter how skilled of a person you hire: if existing processes, plans, structures and habits are still in place in the organization, a star programmer in your organization is likely to become disgruntled, ineffective, or both.
How to beat the odds
Based on decades of application development and maintenance experience, Ontology2 takes a systematic approach to software projects in crisis. The first phase of engagement will likely involve a site visit and will involve interviews with stakeholders in the project such as product managers, software developers, and other staff. We'll also apply our Real Semantics toolkit to make a map of your software, its dependencies, your requirements, etc.
At this point we'll develop (together with you) a model of the value that your project has for your organization and use this to model the costs and benefits of any planned solutions. This step is essential, yet often neglected, because we don't want to proceed unless we have a plan that we can believe in.
Execution of this plan will (likely) involve changes to your development process and tooling as well as training and coaching of your existing team to get the most out of them. All of these changes, including changes in software architecture will be delivered in a way to construct consensus and maximize trust. We can help you add new team members and get them integrated into your team; if you need temporary work, we can deliver it from our network as well as trusted outsourcing partners.
Real Semantics: A Unique Toolset
Real Semantics grew out of our work on making sense of large general-purpose knowledge bases such as DBpedia, Freebase and Wikidata. We came to realize that the most valuable data for any organization was its own data, and that open knowledge bases were useful as reference data to align customer's data with geography, outside organization, regulations, and other standardized terms.
The goal of Real Semantics is to target multiple difficulties that people encounter with real-word messy data: both when it is stored in a data lake, but also when it is exchanged between different systems and organizations. To meet this goal it needed to work with CSV, XML, JSON and other formats, but we discovered that the most important data format it needed to work with was native Java objects, since Real Semantics is written in Java. For instance, to open a file, parse a JSON document, or send a notification, Real Semantics has to create, configure, and call methods on Java objects. (The same would be true for any other language for which a framework is written in; this is central insight of the OMG's Meta-Object Framework.)
At that point, the ability to transform the content of Java objects to and from RDF was a critical capability, but it soon became more than that. Soon we started adding features that would write source code for new Java objects based on RDFS and other schemas, and then, that would produce RDF schemas from existing Java objects (with or without source code.) Quickly, Real Semantics was closely integrated with the Maven build system, Spring, and other tools of the trade.
Although it wasn't part of the original plan, Real Semantics developed the ability to look deeply into a Java-based system and create a map describing the objects, files, build process, and dependencies of the system. People working on Java frequently struggle with Maven, Spring, and other toolkits that are hard to understand without a global view which frequently proves elusive. For instance, when different .class files with the same name exist in multiple JAR files, the "leaky abstraction" of classloading means that different versions of the class could be loaded in different situations -- resulting in failures that are frustratueing to debug. Real Semantics restores a global view of your system, peering through abstractions to see the system as it really is, rather than it is supposed to be.
Get On Track
Managing a software project that is running late, over budget, or has become intractable to maintain is stressful, particularly when it leads to trust breaking down in your organization. Situations like this don't get better on your own, and it is important to get a second opinion right away. Contact us at inquiries@ontology2.com or call (607) 539-6254 to schedule an initial consultation to discover how we can help you get back on track.