“As soon as I put a man in command of the army, they all wanted ME to be the general. Now it isn’t so with Grant. He hasn’t told me what his plans are. I don’t know and I don’t want to know. I am glad to find a man who can go ahead without me. He doesn’t ask impossibilities of me, and he’s the first general I’ve had that didn’t.”
— Abraham Lincoln, upon appointing Grant to overall command of the Union Army
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”.
If engineers faced no constraints, the Golden Gate Bridge would have been built out of Titanium, painted in gold leaf and had the busts of every designer on the pilasters of the side rails. Constraints in a Software Engineering environment can be obvious, like the language for the code to be written in, the database that will be connected, legacy systems integration points and the office environment that everyone writes their code. Less obvious (some would debate the “less” here!) constraints are deployment systems and hardware, delivery dates, Quality Engineering/Assurance windows, customer demographics, Marketing and Advertising purchase windows, integration dependencies from other teams, long-term maintenance of hardware and software, etc…
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”.
Just because you can’t build your bridge out of Titanium, or your clients don’t use Java, or your ITOPS team can’t buy you the latest T-2000 running Debian Linux, means that you have an excuse to deliver less than you promised. Careful planning, collaboration with internal and external stakeholders, and holding yourself responsible for what you say and do is the professional way of doing things. Here is a checklist of often-ignored constraints:
- 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?
- Is your schedule realistic?
- 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.