This man is why my father became an engineer
As a boy growing up in West Virginia, my father wanted to study science but a high school teacher convinced him he had no talent for it.
That man was not why my father became an engineer.
My father joined the Navy, served in the Korean War and became a non-commissioned officer.
While enlisted, he took a class in radio/radar technology. The instructor, a well-respected engineer, turned out to be a great teacher – at least for my father. Which is great enough for me.
My father became the best student in the class. The instructor’s encouragement convinced him to pursue a career in engineering.
My father earned degrees in electrical and a nuclear engineering and made a long career working with technologies evolved from those he learned in that first class.
Now retired, my father decided to find out who this teacher was who had made such an impact on his life.
Nick Holonyak invented the Light Emitting Diode (LED). He is winner of the IEEE Medal of Honor.
Before that he was the first post graduate student of John Bardeen who with fellow Nobel Laureate, Walter Brattain, invented the first transistor.
Somewhere in between these accomplishments, he taught engineering to a class of military personnel.
When my father speaks of Nick Holonyak it is with gratitude and wonder.
My father, the engineer, encouraged me to love science. I studied mathematics and physics and make my living building software.
I encourage my grade school aged daughter to love science. This year, my daughter’s robotics team competed at the New York City FIRST LEGO League Championship.
These are perhaps small things to a man who assisted Nobel Laureates, won prestigious engineering awards, worked at Bell and GE Labs and continues to teach at a research university in a position he’s held for over forty years.
But Nick Holonyak is the reason my father became an engineer. His teaching kindled an enthusiasm that is a source of generational wealth to our family.
Thank you.
More well-wrought crap lovingly crafted for your disposal
– or – building the wrong thing, really, really well.
The epitaph of many agile teams.
You can optimize your construction practices as much as you want but if there is no discernible need for what you’re building…
The goal is not to build crap well. It is to find a way each day to do less and less crap and more and more not crap.
If this were easy, there’d be a lot more software that people should really get there hands on.
Let’s all look in the mirror on that one…
Agile software development: business value and human values
I’ve written about agile software development as an ongoing, perhaps excruciatingly gradual, conversation on the definition of value.
We need a place at the conference table. But we also need a forum and language to discuss the human values behind the way we aspire to work.
“… I’ve got to have more experience with junior [children] than a lot of the people who are telling me what I should be doing with them… I think I could help bring a lot to it and nobody ever asks…They just go ahead and proclaim and we have to follow.” -– Anonymous Teacher
This quote is from a study on the failure of education reform movements, called What’s Worth Fighting for in Your School?
, by Andy Hargreaves & Michael Fullan.
Reform often fails because reformers don’t engage individual contributors in the goals. Rather, they impose practices upon them. The attempt to improve the classroom actually makes the teacher less effective and sets them against reform.
Sound familiar?
The landscape of broken agile adoptions is composed of attempts to make software development “faster, cheaper, better” without embracing the experience and creativity of our core asset, the software developer.
We need to focus a little less on specific practices and a little more on building consensus among our peers over a shared set of values which despite human fallibility and economic necessity inspire us to do good work.
The Manifesto for Agile Software Development is an attempt by thought leaders to capture these principles. As with all documents, it is an artifact of a moment created to address that moment’s opportunities and constraints.
If we take the “Manifesto” as terms and conditions, something to read and sign before we advance to practice then we glide over the surface of things. It’s not what was written but why people felt the need to write it.
If we take the “Manifesto” as a complete expression, then as happens with codes of ethics, we will use its silence on certain concerns and nuance in the interpretation words themselves to excuse actions by others and even justify the harm we do ourselves.
The “Manifesto”, as with any other artifact in agile, is simply a reminder to have a conversation.
Martin Fowler discussing gender disparities in the industry:
How about a community where women are valued for their ability to program and not by the thickness of their skin? How about a community that edgily pushes new boundaries without reinforcing long running evils?
Bob Martin lobbying to add a fifth principle to the Manifesto itself:
“We value craftsmanship over execution” (or “craftsmanship over crap”)
But the discussion isn’t between thought leaders. It involves every practitioner.
We are here to create long-term value. To build businesses, careers and an industry. This is a labor of years not the current iteration.
If your concerns are entirely short term, then there are less disingenuous ways to extract wealth from people’s effort than to claim you are “agile”.
If you are agile, then you are accountable to the creativity and well-being of the teams with whom you collaborate. You are accountable for the security of end users and the benefit they derive from the software you create.
We are not tools. We are knowledge workers. What we create carries with it the way it was created. What we create is in some profound way us.
Agile software development and “value”
As advocates of agile software development we focus on practices.
The hype on those practices is they produce software, “faster, cheaper, better.” And we sell our efforts with the promise of, “delivering value.”
We speak of value as if the definition is shared, self-evident, contained within our backlogs and measured by our burn ups.
At the same time we minimize the hard and long the struggle to achieve mastery, identify and address a material need, and sustain creativity and quality.
So, we win the opportunity to labor with our teams to incrementally deliver potentially shippable units of code to stated business priorities.
When those priorities are pointless, so is the software.
When those priorities are tactical and subjective, the values behind agile practice — sustainable effort, maintainable code, self-directed teams, collaboration and trust — become irrelevant.
The truth is there are definitions of “value” that sell us out whether or not material success accrues to someone as a result of the software development effort.
And so, an agile adoption that is true to its participants is an ongoing, perhaps excruciatingly gradual, but substantive conversation with the larger organization on the definition of value.
A set of practices is only companion to the human values that give our work meaning.