Enterprise Software Development: 11 Tips to Help Avoid a Mess on Your Hands

There Are Many Impactful Subtleties CIOs and Other Ranking Corporate Officers Should Be Aware of When Looking to Develop Enterprise Software for Their Companies

It may be no ground-breaking news, but roughly half of all projects related to the development of enterprise-grade software turn belly up initially, and either have to rescued by their owners to survive (certainly, by throwing tons of good money after bad) or are just abandoned to their fate.

Numerous headlines having been made and whopping losses (some have reached hundreds of millions of dollars) having been incurred by iconic market players in completely different industries, we seem to be no closer to a solution that we were, say, 10 years ago. Why?

In our view, in enterprise software development, there are just always too many devils in the details on different levels, both technical and management. What complicates matters a lot, a lot of the time they have to be dealt with jointly by the different project stakeholders, including those, representing the client. Besides, many of the things that seem no big deal, but are, potentially, able to derail a project, have to be picked up empirically. They are not always widely available as part of formalized domain-specific knowledge.

In this article, we’ll share several such things of the myriad we’ve gleaned while implementing client enterprise software projects. We’ll do so in the hope that, if your company is faced with the massive task of having an enterprise application developed for it, these tips may help you keep better tabs on your software development contractor (that, as time has shown, may, or may not be aware of them).

Big-Time IT SOLUTIONS to BIG-League ENTERPRISE CHALLENGES

Development-Related Tips

1. First and foremost, most enterprise software development projects are, usually, wide-ranging development efforts that involve a number of experts, each having their own coding habits and their own idea about the way code should look like. After a while, their conflicting views and habits result in a mess that is hard (if impossible) to straighten out, and prevents newbies from getting a handle on the project specifics within a reasonable space of time.

   Never embark (or let your contractor (s) embark) on an enterprise software project without introducing detailed Development Guidelines. These guidelines must stipulate a set of rules that aim to ensure uniformity of the various kinds of input, offered by the project’s multiple contributors. They must also specify and detail your requirements for the code to be written (the use of blanks, tabs, case styles, naming conventions, etc.).

   Make sure all those, involved with the project, are aware of, and follow these rules.

2. Similar to Point 1, quite often, the several project teams implementing an enterprise software project, have a different idea about what can be considered “done” or a duly fulfilled task. This entails frequent misunderstandings, longer turnaround times, and, sometimes, even, attempts at blame shifting.

   That is why, prior to kicking off an enterprise software development project, one should discuss with all the project teams, compose and introduce formalized “considered done” criteria that will be upheld by all the teams, involved in implementing the project. For example, these criteria can include:

   • Coded

   • Compliant with the project-related guidelines.

   • Meets the project-specific acceptance criteria.

   • Committed to a Team branch.

   • Compilable

   • Duly documented

   • Unit Test coverage is no less than 80%.

   • Notification sent by email to

3. It is simply imprudent to start an enterprise software project without a proper definition of the areas of responsibility and corresponding personnel appointments.

   With Agile enterprise software projects, a good rapport between the different project teams is central to the project’s success. This is best achieved with the help of written working agreements between these teams, adopted project-wide.

   For example, such a written working agreement can include the following clauses:

   • Code is written solely in accordance with the project-specific development guidelines.

   • For Sprint-related work, Team branches are used.

   • Only those features, that are in compliance with accepted the “considered done” definition are committed to the Common development branch.

   • Nothing is committed to the red build.

   • No code that has not undergone a code review is committed.

   • The Product Owner is constantly available to answer questions by the team members.

   • Nobody is ever late for a meeting.

   • Nobody comes to a meeting unprepared.

   The whole thing must be supported/promoted by the PM.

4. It is imperative that all project tasks are track-recorded regardless of their size. Failing this, you may wind up with a massive amount of poorly manageable code, dealing with which will be irksome and extremely time-consuming. Your developers will have to turn themselves into full-time investigators every time they come across an obscure spot in the code. Again, this spells a real pandemonium for those, joining the project at a later stage.

   From our experience, you can enhance the readability and ease of use of your code base immensely by integrating Git and Jira, and using this integration for source control purposes. It will become possible to immediately view history for any of the code changes (in plain talk, when and why the change was made, who made it, and what exactly was done). In any event, it is an absolute must that one follow the Agile paradigm: : “Plan what you do, do what you plan”.

   Project Management-Related Tips

5. See if there is a need for Stakeholder Management being part of your Project Management process (which is, very frequently, the case with enterprise software development efforts). Once unidentified at the beginning and overlooked later, this need becomes an insidious scourge that can, in due time, affect a project negatively at on an even greater larger scale than a major technical issue.

   So, just in short, what is Stakeholder Management and why is it of so much importance?

   Stakeholder Management is the process of identifying the various possible pockets of resistance within an organization, formed by those employees, whose interests are opposed to the project-empowered change.

   While few executives want to believe there can be undercurrents in their companies that are at variance with whatever is said at high-ranking meetings and festive corporate bashes, this happens all the time. Most frequently, this happens as changes that may affect the interests of a specific group (s) of employees (or, even, those of individual employees) begin to loom large and send jitters across the organization, while those concerned fail to see any upsides to the forthcoming innovations.

   You, simply, cannot afford not to identify such employee groups or employees, and not to mitigate or dispel their apprehensions by explaining to them how the project to be implemented will benefit them. Elseways, the fallout can include a severe lack of cooperation, deliberate protraction and missed deadlines, and, under the worst of the possible scenarios, a stalemated project it will cost you a mint to bring back on track.

   There are multiple ways you can influence and remedy the situation. Your options here can range from corporate perks and the ability to acquire new, valuable skills, to the opportunity for these guys to switch to less chore-like and more interesting tasks.

6. With Agile-driven enterprise software development projects, Product Owners tend to be regarded as a kind of semi-deities, and are not, even, always available for a conversation. This approach is a totally wrong one.

   New requirements come into being continually, and things get modified on the fly all the time. You need the Product Owner to be an integral part of the team (both constantly within reach and actively involved in the team effort) for those changes to be handled properly. He or she must share full responsibility for the results of the team’s work efforts, as well as take active part in the performance of solution reviews, conducted at reasonable intervals together with the other team members.

   Testing Automation-Related Tips

   Testing Automation is, frequently, regarded as a kind of a silver bullet when it comes to enterprise software development projects. It is widely held that once you have a certain number of automatic tests written everything is well-taken care of QA-wise. This is a very troublesome fallacy.

   In actuality, in terms of major enterprise software development projects, Testing Automation pans out only when handled properly.

   These are the more meaningful tips we could offer testing-wise for “mess avoidance” purposes:

   There are multiple ways you can influence and remedy the situation. Your options here can range from corporate perks and the ability to acquire new, valuable skills, to the opportunity for these guys to switch to less chore-like and more interesting task

7. Keep all your tests small. Your tests must pinpoint a specific problem and focus on a specific task. One should try to minimize the number of wider-ranging tests. Preferably, the latter should only include a small quantity of integration tests that aim to ensure that all the system modules interact seamlessly. Otherwise, if a test flunks at a future date, it will become immensely time-consuming and labor-intensive to unravel the long related testing history in order to get a fix on the problem.

   If you have any lengthy or convoluted tests already being used or in the works, have those split into smaller ones: even if everything’s Ok so far, the likelihood of future problems arising is quite high.

   Notably, overcomplicated and overextended tests can significantly hamper, or, come to that, ruin altogether your Continuous Integration process, if it is the approach you use.

8. All the tests must be unrelated to one another. If this is not stipulated from the outset, you may well encounter a couple of really unpleasant scenarios.

   For example, if your tests are linked in one way or one another, one single test failing can cause several hundred other ones to go haywire without giving you any clue whatsoever as to which of them is at fault for the mess.

   Similarly, any change made to one of your tests will inevitably entail making changes to the rest of your tests. In addition to the whole lot of trouble the above scenarios are bound bring about, both of them will also be sure to set your testing costs soaring.

9. Stick to Martin Fowler’s test pyramid: the vast majority of your tests must be Unit ones and only a very small part of them can be Integrated and UI tests.

10. Developers, no matter how skilled and good at programming, tend to be lousy indeed at writing test cases. We’ve seen plenty of this stuff and there are either lots of cumbersome overlaps or something that needs to be tested just gets left out.

    Conclusion: all test cases must either be written by a QA engineer (this should, preferably, be a separate project role), or, at least, reviewed and approved by a qualified QA expert. Quality Assurance must become part of the development process.

11. To ensure smooth and uninterrupted Continuous Integration, one should make sure his builds don’t take too long to be executed, and the build results are analyzed reasonably quickly.