Constraints are things that we live with in our daily lives, accept them, and move on. With software engineering groups that are well-established and have strong leadership, constraints can get legs of their own and become excuses for not delivering projects on time, not building something correctly, or even stepping outside Enterprise Goals because “they do not fit within our design.” Many times the inability for an engineering team to confront a constraint will go so far as to create blame, cast dispersion and create a poison atmosphere to anyone that “gets in their way”.
Consider a “Software Team” that is responsible for building high-transaction software for a large enterprise. This enterprise has instituted the standardization of all hardware within an infrastructure to allow for better purchasing, streamlined maintenance and quicker deployments. The benefits from a shared infrastructure environment are obvious from a cost-savings standpoint, and when the ITOPS group engages the teams building software (and vice-versa), hardware that meets the enterprise goals for both teams will be integrated into the final implementation. This software team did not participate, and further, believes that the ITOPS group has very little competence.
The “Software Team” purchases all of its hardware outside of the system and any products that need to integrate must do so on their terms. Often the kernels of the OS are different, requiring the ITOPS team to have additional resources and skills to maintain this completely separate branch of hardware and deployments. Since the “Software Team” is politically powerful, it gets what it wants. The company suffers because the arrogance of a Software Team and their inability to live within constraints causes other teams to pick up their slack.
Another constraint is to provide services that are consumable by all clients. If a team is Java-centric and only builds services that can be consumed by Java clients, this causes a great deal of difficulty for other teams within an organization that do not develop within a JVM. Soap, REST and other XML-RPC interfaces should always be considered first, along with other OS/Language independent methods. Groups that build products for themselves and do not collaborate with their client teams are not facing up to constraints, and will always deliver inadequate products that are late, incomplete and full of excuses.
Excuses. Excuses abound within a team that cannot face up to constraints. “Wha-happa-wuz” will be the first things heard by management, along with a list of “things out of their control” that affected why their product was late, broken, inadequate or some combination of all three.
Constraints are things that affect your product but are “out of your control”.
Is the software being delivered in-line with the business stakeholders vision?
Are you trying to force external resources into a particular technology?
Can your product/application be supported on the existing/implemented hardware platforms?
Has the schedule been set to allow for the usual delays in deployment, testing and configuration?
Have all consumers or clients of your product/application been consulted and had a chance to fully comment?
Is your team really the proper group to be building the software?
Are non-engineering stakeholders like marketing and sales properly informed of all risks and deliverables?
This article is intended more as a “gut check” to an engineering team. If, as a team, products are consistently late, stuck in testing, not meeting expectations or hard to maintain, it is “gut check time”. It’s very easy to blame others; demand “impossiblities” of management and other groups and cast dispersions. It is a harder, but more successful approach, to look at what impedes the group, accept them as constraints and work within them.
This entry was posted in Enterprise Development, Quality Assurance, Software Dev Processes. Bookmark the permalink.
← Airline Passenger Etiquette — When you're NOT the only one on the Plane!