- Beneficial change results from cycles of learning, doing and self-reflection.
- Success derives from delivering small things of value regularly and often.
- A discreet piece of work is either done or it is not done.
- Better to risk a bad decision than make no decision at all.
- The wisest decision is made just before it can be most efficiently acted upon and no earlier.
- Most features will receive little or no use. 60% of what you want is better than 100%.
- Plans document one scenario that will not happen and describe some other application than the one that was built.
- On time and on budget are not synonyms for success.
- In human endeavor, every enlightening truth contains a lie. The road to hell is paved with…
Tag Archives: good work
An MBA Oath – another non-profession’s search for a standard of ethical conduct
There’s a movement among the students of the MBA program of Harvard Business School for an MBA Oath of ethical conduct. Read the oath here.
From a June 4th article in the Economist:
The student oath is part of a larger effort to turn management from a trade into a profession…
This is the exact debate going on in Software Development — emerging profession or craft?
One of the two main criticisms of the oath and of the whole idea of turning management into a profession, particularly in business-school faculties, is that it is either unnecessary or actively harmful… (by) promising to “safeguard the interests” of colleagues, customers, and society, are the future captains of industry simply short-changing their shareholders?
Defenders of the oath reply that the goal of maximising shareholder value has become a justification for short-termism and, in particular, rapid personal enrichment. They are concerned about managers doing things that drive up the share price quickly at the expense of a firm’s lasting health.
The second complaint is that the oath’s fine words are toothless.
Even these cheerleaders admit there are differences between practising management and, say, medicine. They concede that no self-regulating professional body for managers could possibly monopolise entry to the profession
We can debate that a practice has ethical consequences, i.e. that it has a larger array of stakeholders who can be harmed or benefited by the daily decisions of practitioners – without calling for accreditation, lincensing, certification, standards bodies, and regulation.
Developers should consider end users, society and our common reputation even as managers consider long-term investors, employees, their industry and the larger economy.
Name a widespread activity that isn’t abetted/enabled by software systems. Even the debate over an MBA Oath:
As for punishing unprofessional behaviour, Mr Khurana (Rakesh Khurana, a professor at Harvard Business School) is inspired by the internet rather than by a closed council of grandees. From open-source software to eBay and Wikipedia, new systems of self-regulation are emerging based on openness, constant feedback and the wisdom of crowds. These could be adapted, he thinks, to provide effective scrutiny of managers.
If anything about this strikes you as not true, I’d love to hear why.
Ditching on the Hudson
Here’s to competence, experience, courage and tremendous luck.
You’re an Experiment
I’m on the management side of the labor divide and yet I’ve never held a position my parents would consider a permanent job. To work these days is effectively to be employed at will.
I once had a senior executive tell me that my team was an experiment. To prove the value of development staff, we had to replace an outsource, maintain their legacy applications, and deliver a challenging new project. If we failed, next year’s budget would go to re-establishing the outsource.
We faced a hard date, skeptical clients and a steep learning curve but we had an honest leader, the means to succeed and a way of measuring it. All we had to do was execute.
I never felt more control over my fate.
A family friend works for Doctors Without Borders. His labor benefits society in ways that will outlive him. In the balancing act that is my life — privileged by world if not New York standards — I’ve deferred, if not entirely foregone legacy. My job is about significance and achievement. Significance comes in providing for my family, not only a biological imperative but a profound joy.
Achievement rests in approaching each year as if it were an experiment. What accomplishment justifies my continued employment? What one thing should I do to materially advance the interests of my employer, our customers and/or my team? It’s the chart of that course that makes me show up in the morning and it’s sightings along the way that allow me to sleep at night.
Love of Craft (Continued)
SD Times has a brief item on the Standish Group CHAOS Study update. In 2006, 65% of sampled software projects were canceled, significantly late and/or over-budget. Over ten years of thought and practice have improved our success rate by a meaningful but disappointing 19%.
Business execution shares more than equal credit for our state of play. Four of the first five Standish Group project success factors are engaged, empowered and pragmatic product management.
There will always be a background failure rate no matter how excellent technical execution becomes. Things change and opportunities involve risks. Some well-executed projects will always fail to pan out. Still, 65th percentile is a mean aspiration.
I haven’t met a talented developer or development manager who wasn’t obsessed with self-improvement. Yet a focus on self isn’t enough. Standing out in the crowd may benefit individuals but it diminishes our craft. The failure around us lowers the hopes of society for what we can achieve.
Principle 7 of The IEEE Computer Society Code of Ethics says we should:
7.07. Not unfairly intervene in the career of any colleague; however, concern for the employer, the client or public interest may compel software engineers, in good faith, to question the competence of a colleague.
Inferior work embarrasses me. Behavior that perpetuates inferior work infuriates me. But when should we step beyond criticism of code to criticize those who author it? First, in good faith we should search our motives for self-interest and vanity. Opportunism is bullshit. Bullshit devalues truth. Bullshit destroys trust.
Ultimately we have a responsibility to protect the interests of those who pay us and the larger community who benefit from our efforts. We have a responsibility to society and the reputation of our industry upon which our potential to contribute to society depends. It’s our duty to find a way of expressing criticism that stands some reasonable chance of benefiting those interests.
Easier said than done where a power imbalance exists. As Ken Schwaber says in Agile Project Management with Scrum
, “A dead sheepdog is a useless sheepdog.”
With all that to balance, how do we sleep at night?