There Are Many Impactful Subtleties CIOs and Other High-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 enterprise-grade software development projects turn belly up when first released. They either then have to be rescued by their owners (certainly, by throwing tons of good money after bad), or just get abandoned to their fate.
Numerous headlines having been made and whopping losses (sometimes hundreds of millions of dollars) incurred by iconic market players in a bunch of industries, we seem to be no closer to a solution than we were, say, 10 years ago. Why?
In our view, there are just too many devils in the details on both the technical and management levels of which even quite experienced enterprise software providers are not yet aware. Many of the things that seem like no big deal, but are, potentially, able to derail a project have to be learned empirically. These things are not mentioned as part of any formalized domain-specific knowledge.
To complicate matters even further, a lot of the time these hazards have to be dealt with collectively by many different project stakeholders. Some of these stakeholders represent the client.
In this article, we’ll share with you several such empirical insights of the great many we’ve picked up while building enterprise-grade software. If you are looking to develop an enterprise application, these tips may help you keep better tabs on your software development contractor.
Big-Time IT SOLUTIONS to BIG-League ENTERPRISE CHALLENGES
Development-Related Tips
-
First and foremost, most enterprise software development projects usually represent wide-ranging development efforts that involve a number of experts. Each of these experts has their own coding habits and their own idea about the way code should look like. After a while, these often conflicting views and habits result in a coding mess that becomes difficult (if not completely impossible) to manage or straighten out. The quality of the code prevents newcomers from getting a handle on the project specifics within a reasonable space of time.
Because of this, you should never embark on any enterprise software development project without introducing a set of detailed and well-thought-out development guidelines. These guidelines must stipulate the rules that will allow you to ensure the uniformity of all the inputs, provided by the different project contributors. Notably, the above rules must detail the requirements for the code to be written, i.e. the use of blanks, tabs, case styles, naming conventions, etc. Make sure that all those, involved in implementing the project, know and strictly follow your development guidelines.
-
Similar to Point 1, quite often the several development teams, engaged implementing an enterprise software development project have varying ideas about what can be considered as “done” or a properly completed assignment. This entails frequent misunderstandings, longer turnaround times, and, sometimes, even, attempts at blame shifting.
That is why, prior to starting any enterprise software development effort, one should compose, discuss in sufficient depth with all the development teams, and formally introduce a set of “considered as done” criteria to be universally upheld by all of the teams involved. For example, such 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%.
-
-
It is imprudent to start an enterprise software development project without defining the areas of responsibility and making corresponding personnel appointments.
With Agile enterprise software projects, a good rapport between the different development teams is central to a project’s success. This is best achieved with the help of written working agreements between these teams, adopted project-wide.
For instance, such a written working agreement can stipulate the following rules:
-
Any code is to be written solely in accordance with the project-specific development guidelines.
-
For Sprint-related work, Team branches are to be used.
-
Only those features that are in compliance with the adopted “considered as done” definition are to be committed to the common development branch.
-
Nothing can be committed to a red build (or a build that has failed testing and, thus, is not compilable for some reason).
-
No code that has not undergone a code review can be committed.
-
The Product Owner is to be constantly available to answer questions, posed by the team members.
-
Nobody can ever be late for a meeting.
-
Nobody can come to a meeting unprepared.
The above rules must be supported/promoted by the PM.
-
-
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 your code base’s readability and ease of use immensely by integrating Git and Jira, as well as by using the 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 a 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, and do what you plan."
Project Management-Related Tips
-
Try to determine if there is a need to make Stakeholder Management part of your Project Management process. Once unidentified at the beginning and overlooked later, this need becomes an insidious scourge that can, in due time, affect the project negatively on a much larger scale than a mere 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 any existing pockets of resistance, created by those of an organization's employees, whose interests are opposed to the project-empowered change.
Few executives want to believe there can be some undercurrents in their companies that are at variance with whatever is said at high-ranking meetings and festive corporate parties. Alas, this happens all the time. Most often, this happens when the changes that are likely to affect the interests of an individual employee or a specific group of employees begin to loom large and send jitters across the organization. In this case, some of those concerned fail to see any advantages the forthcoming innovations can create for them personally. Simultaneously, they set too great a store upon the possible disadvantages and risks they may be exposed to.
You simply cannot afford not to identify such employee groups or employees in order to alleviate or dispel their fears by explaining to them how your project will benefit them. In the absence of this, the fallout can include a severe lack of cooperation, deliberate protraction and missed deadlines, and, eventually, a stalemated project it will cost you a mint to bring back on track.
Your options here can range from corporate perks and the opportunity for such employees to acquire some new, valuable professional skills, to giving these guys a chance to start performing less chore-like and more interesting tasks.
-
With Agile-driven enterprise software development projects, Product Owners tend to be regarded as a kind of semi-deities, who cannot, even, always be available for a conversation. This approach is totally wrong.
New requirements come into being continually. Things get modified on the fly all the time. For these changes to be handled properly, the Product Owner must be an integral part of the team (both constantly within reach and actively involved in the team's efforts). Moreover, they must share full responsibility for the results of the team’s work and take active part in the performance of solution reviews, conducted at reasonable intervals together with the other team members.
Testing Automation-Related Tips
In enterprise software development, Testing Automation tends to be thought of as a kind of a silver bullet. It is widely held that once you have a certain number of automatic tests in place, everything is well-taken care of QA-wise. This is a very troublesome fallacy.
In actuality, Testing Automation pans out only when handled properly.
These are the more meaningful tips we could offer testing-wise for “mess-avoidance” purposes:
If you already have some lengthy and complicated tests being used or in the works, have those split into smaller-sized ones: even if everything’s Ok so far, the likelihood of future problems arising is quite high.
-
Overcomplicated and overextended tests can significantly hamper, or even ruin altogether your Continuous Integration process (if, of course, it is the approach you use).
-
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 the different system modules interact seamlessly. Otherwise, if one of your tests flunks at a future date, it will become immensely time-consuming and labor-intensive to figure out what the problem is. One will have to unravel a long and convoluted testing history to get to the bottom of the problem.
-
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 nasty scenarios.
For example, if your tests are linked in one way or one another, one single test failing may 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 both the scenarios can create, they will also be sure to set your testing costs soaring.
-
Stick to Martin Fowler’s test pyramid. The vast majority of your tests must be Unit ones. Only a very minor part of your tests can be Integrated and UI tests.
-
Most software developers, no matter how skilled at programming, are lousy indeed at writing test cases. We’ve seen plenty of this stuff and there are either lots of overlaps or something that really needs to be tested just gets left out.
Conclusion: all test cases must either be written by a well-qualified QA engineer (this should, preferably, be a separate project role), or at least be reviewed and approved by a well-qualified QA engineer. Thus, Quality Assurance must become an integral part of your development process.
-
To ensure smooth and uninterrupted Continuous Integration, you should make sure your builds don’t take too long to be executed and the build results are analyzed reasonably quickly.
