Debt Ceiling Debacle
Is anybody watching this fiasco unfold? It “occurs” to me as a hostage situation. Far right factions in the Republican Party have decided to hold the economy hostage to push through their agenda, and no one seems to be willing to take them to task or talk some sense to them. It now looks like they’ll get their way and saddle to poorest and neediest in our nation with mending the damage that the Bush era machine set in motion. Not only are there to be no “new taxes”, we’re extending the tax cuts to the wealthiest Americans and cutting social programs to pay for it. The only point of contention now is how the Republicans can avoid cutting defense spending as deeply as the bipartisan “supercommittee” has suggested while at the same time reducing the deficit by an amount equal to the debt we’ve already incurred (and now have to pay for) without raising revenue. It looks to me that the greed has moved from Wall Street to Capitol Street by proxy.
They would have us believe that their party was not responsible for taking a nation with a balanced budget and no federal deficit and turning it into a nation with historic budget deficit. When the greed of Wall Street and the deeply red budget caught up with us, we were headed toward a depression. They would have you to believe that TARP and stimulus were ineffective in preventing anything, but my impression is that things could have been much worse if the leadership that put us in this situation was still at the helm.
I don’t think there’s any evidence that the two party system still works. Neither party has been able to muster the combination of leadership and insight necessary to right the ship. The far right sees no reason that we need to pay taxes for the services they receive, and the left has been unable to nudge them to a middle ground. Paying for what we’ve spent by collecting revenue and cutting spending would be compromise. Compromise seems to be a word that has taken on a derogatory connotation as unpalatable to our generation as the word “thrifty”. Economy and good management are no longer seen as ideals worth our attention, and besides, the word “thrifty” keeps bad company. It’s one of the principles in the Scout Law, and they all seem to have fallen into disfavor. A scout is:
Trustworthy
Loyal
Helpful
Friendly
Courteous
Kind
Obedient
Cheerful
Thrifty
Brave
Clean
and Reverent
We’re intent on pressing two simultaneous wars on the Asian continent when we can’t keep our workforce employed. One would have thought we would have learned our lesson by now on attempting a prolonged military engagement in Asia with no clear definition of success or a clearly understood plan on handing over the responsibility and getting out. We think we’re bringing the fight to the terrorists responsible for 9-11? That’s not true in Iraq, and I’m not so sure about Afghanistan either. Afghanistan has behaving pretty much the same way for a thousand years. Killing them only gives them something to fight for and makes them stronger. A better approach to Afghanistan might be free MTV and McDonalds.
But then again, that hasn’t worked in our inner cities. Tensions still run high along racial, economic and ideological divides, and neither Lady Gaga or Big Macs seem to have brought the violence to a close.
Relevance
It’s a little sad that the comments I see here invariably lack relevance. I rather see flames or derision than an oblique post that makes you wonder if the reader even saw the piece they’re leaving a comment about, no matter how nice they appear. My suspicion is that it’s a new form of spam, and I’m beginning to suspect that a large percentage of the comments I’ve neglected to approve were generated by bots, perhaps crafted to drive some hit ratio up on a linked site. I guess that with the millions of blogs out there, the odds of a real human finding my trivial little site is next to nothing, so spam-bots are about all I should expect to see. I guess that it takes relevance to generate relevance. Have I said anything that would speak to the human condition or offer a solution to the problems that confront my cohabitants of planet earth? Probably not. Do I have opinions? Sure. Many of my problems have been directly related to my perspective. The folks I see day and day out have choices. We can isolate from our fellow man and our Higher Power, or we can choose to engage with reality and be a channel for our HP’s love.
The choices we make can shape the planet for the better or propagate its problems. Accepting the status quo and failing to speak out against what’s wrong in society is a choice, and it’s one I’ve made far too often. We have problems, and the loving thing to do is to point them out, not ignore them, hoping they’ll go away. There is a machine in motion that counts on our sleepy acceptance that they’re nothing we can do about injustice, suffering and the plight of the environment. The status quo is very profitable to a very few, but endangers the survival of our species. The only way to change the status quo is to influence our institutions though our choices. The way that works with our political institutions is obvious. We express our views and vote with ballots. Commerce and industry take their ques from the demand of the consumer. We vote with our checkbooks. Our religious institutions are empowered by their parishioners. We vote with our attendance and our financial support. The keys are having the desire to understand the issues, doing the research, making a choice and voting your heart. And that’s *all* about relevance.
the meaning of work
I remember a poster on the cube wall of a coworker a few years ago that posed a question something to the effect of “if a tool performs the task, is it still work?” To put it another way, as an information worker automates more and more of the daily mundane tasks with less and less human intervention required, at what point do those element of the job description stop being “work”?
I’m going to venture an opinion that “work” is much like a stream. You can step in the same stream but it’s never the same twice, the water moves on. Over time, we can hope to find ways to minimize the mundane, but the stream is always moving. The repetitive can be automated, but technology and tool sets are always changing, and our focus naturally looks to ways to link together automation in a way that’s repeatable and measurable. The work at hand becomes more a function of looking for patterns then finding and implementing tools that add value in the simplest repeatable and maintainable way possible. Leveraging the work of others.
Dawn of a Virtual Classless Society?
One definition of the proletariat is the class of people that have only their labor to support them, i.e. don’t own the “means of production”, classical factors of production including instruments of labor and subjects of labor. I would assert that we have entered an era where a large segment of production centered around information has made this concept obsolete. The means of production (or MoP) of a software based product today is free, at least from the perspective of a developer with an idea and the skills and desire necessary to implement it. The tools required to develop quality software can be accessed or downloaded with zero monetary investment. This includes development of enterprise scale applications. There are no licensing or maintenance costs associated development using the JDK, and like it or not, Java/EJB has a commanding lead in the enterprise marketplace over it’s closest competitor, Microsoft’s .NET. Serious relational databases now exist in the open-source world – MySQL and PostgreSQL for example. World class IDEs exist for Java development that may be used and extended, free of charge. The documentation needed to learn to develop software with these tools is freely available on the Internet. Access to the Internet is free at most public libraries as well as the coffee shop down the street.
According to the MoP article on Wikipedia as it existed on 20100107, when the workers control the MoP directly, it embodies the pure ideal of socialism:
“In the pure ideal of socialism, such as that ‘communism’ was/is supposed to be, the MoP are controlled by the workers production collectives directly. In fact this situation has only been historically realized temporarily such as in the Israeli kibbutz or the early Soviets before the entrenchment of the communist party as a ‘New Class’, or in isolated or preliminary form such as in the final phase of the Second Spanish Republic, or various experimental utopian communities.”
If this is the case, it may well be that the open-source community accomplished what the Soviet Union could not. Perhaps such a “utopian community” now exists in cyberspace. When it comes to information based products, and we live in an information age, the MoP now rests in the hands of the workers. Development environments, libraries, frameworks, source control systems, collaboration tools, issue/defect management systems – are are freely available under license agreements no more restrictive than the GPL or BSD licenses. Anyone with sufficient will and vision can produce and market a product to the entire planet. Some may argue that it takes considerably more, and this kind of opportunity is only available to members of the Bourgeoisie, since there’s no way to gain the knowledge and skills necessary to bend the available tools and infrastructure to your ends without considerable investment of capital in the first place. That’s not my experience, and I’m more than willing to debate the issue. Any resourceful “potential programmer” can find all they need at their fingertips – including tutorials and a strong support community. All that’s really needed is a recognized need and the willingness to pursue it’s solution.
Thinking about thinking
I watched Jill Bolte Taylor’s talk on the rolls of the hemispheres of the brain yesterday on TED, and it has me thinking more about Zen and Kabalah. Both of these disciplines enjoin the practitioner to learn to control the mind for a metaphysical end, and one of the meditation techniques described as “quieting the mind” sounds very similar to the experience Dr. Taylor describes in her talk about her stroke. The idea that we can move out of the ego based context of the left brain into the right brain’s experience of the universal whole by our own volition is captivating and exciting. To me, this seems like a neurological holy grail on the path to gnosis or bodhi. Having experienced a glimps of this state as a youth, I can understand how people through the ages would dedicate years of hard work to cultivate this ability. Dr. Taylor’s work reinforces much of what I intuitively feel about the nature of my internal dialog and it’s relationship to me and the world around me. It’s easy to conclude that this voice is the self, but the transendental experienceso eloquently described by Dr. Taylor shatters that illusion. The ego is not the self, and allowing the dialog to go silent is not the end of the world. Rather, it is a means to get in touch with our true selves and experience the peace of knowing that we’re a part of something bigger that the ego can comprehend.
software development – current state assessment
I’ve been involved in a variety of disciplines associated with software development for the better part of 30 years, so this installment is dedicated to some “stuff” that may appear obvious to some, but it seems worth restating since I have seen so many examples in our industry of how to develop software poorly. In fact, poor software design is so pervasive that our community will latch onto a new paradigm every few years hoping that it will be the silver bullet to kill the monsters and daemons that plague us. The latest fad that has gripped software development is Agile, and it brings us a development model with a set of principles and a seminal document that can sound revolutionary. For example:
This is quite understandable in light of years of pain and frustration. One of the key elements in Agile is that the people involved are important. It stresses satisfying the customer and accepts change as a natural part of software development, recommending continuous collaboration with the Business User as opposed to accepting or rejecting a specification. It suggests that face to face communication is superior to status reports and piles of documentation. These values represent an important shift in perspective, but they should not be used as an excuse for ambiguous requirements or an unwillingness to generate user documentation. The statement about valuing “individual and interactions over processes and tools” should not be used as an excuse for cowboy coding. Processes and tools can be extremely useful in an Agile environment, and I read the statement to mean that the process and tools should serve the developers, not the other way around. It doesn’t mean we should all stop tracking bugs or stop using source control. It does mean that we need to select tools and processes that fit the development model we’ve agreed to follow.
Let me make this clear, I don’t claim to be an expert on methodology, and I’m not one of the giants that founded the engineering discipline that has claimed so much of my time and attention, but I have learned some lessons about core elements crucial to a successful project, regardless of the development model. Based on these lessons, I have a few suggestions to anyone that feels compelled to subjugate a computer into their service where an existing program will not meet their needs…
1)Manage the interfaces to the development organization.
2)Clearly define requirements to save time, money and sanity.
3)Know your SDLC.
4)Use Source Code Control integrated with Issue/Defect Management
5)Expect developers to produce tangible, demonstrable deliverables.
When work flows into the development organization from a variety of sources, it quickly becomes impossible to do anything predictably. To gain visibility into the quality and delivery of the organization’s output, you must first accept that there will always be planned and unplanned work. Unplanned work may be handed off from a customer support organization through an escalation where a software defect has been identified, or may be the result of testing by QA or development itself. Planned work can be in the form of a project proposed by a business customer, or it can be that a defect has been identified that requires a level of resource commitment where planning becomes necessary. There needs to be a single body responsible for controlling the flow of planned and unplanned work – accepting projects for the planned work, managing the unplanned work queue, and mapping this work against release cycles and resources. Assuming that resources are finite, adding work into the queue means that something will come out for a given release cycle. The important thing here is transparency. It serves the interest of no one to pretend that work can be added without taking something else out.
OK, requirements can change. Heraclitus of Ephesus said the only constant is change – and I think the lesson from that is to accept it as a part of life. Does that mean requirements don’t have value? “A world of no.” In fact, clear, concise requirements are invaluable. A requirement that can be expressed as use cases and translated into test cases give the developer clear direction. There’s a concept that originated with XP that expects the developer to produce test cases and even code up the test classes that generate a negative result before implementing the methods that solve the problem expressed by the test case. If the tests are automated and the results exposed to the business user, the project or exercise has a good chance of being successful. Actually, test-driven development has taken on a life of it’s own, and that’s attributable to the value perceived by all the parties involved – the business users, management and the developers themselves. Test-driven development isn’t possible without succinct requirements. Requirements can change, but the new requirements should also translate into something the developer can test. The dialog between the business user and the developer in Agile totally supports this concept, and the idea of QA participating in development as a team member adds additional synergy to this iterative process by providing a perspective that spans unit test, integration test, performance test, load/stress test and user acceptance test.
The software development life cycle spans every aspect of your development from inception to end-of-life. Not everyone’s SDLC is the same, and can actually vary widely from one organization to the next depending on methodology, the nature of the business and aversion to risk. Within an organization, the SDLC can vary between planned projects and emergency bug fixes, and unless you’re a collective of mythical beings that foresee the future with unerring clarity and never write a line of bad code, there’s a good chance that the associated processes will be iterative. It is quite conceivable that separate process will be necessary for a “full release cycle”, a “partial release cycle”, an “emergency release cycle”, and a “diagnostic release cycle”, however, the closer they approximate a single workflow, the more likely you are to get useful metrics out of your tools. There’s a workflow associated with an iteration through the SDLC, even if it only exists in the minds of the managers and developers. It needs to define the participants, each state, and all of the associated transitions if you intend to use a workflow tool to manage the process, and I would really recommend a workflow tool. Bug trackers are OK at what they do, but issue management with a tool built on a workflow engine is far better at controlling and giving you visibility into your processes.
Segue to source code control. Many SCC systems can integrate to the developer’s IDE and an issue management system. There is a good chance that a time will come that you’ll need to know whether a change for a particular issue is in a given code base. You can fulfill this need by instituting a manual process of entering comments for every revision to every source file checked into your SCC system, or you can automate the task to some degree with an integration. The “richer” the integration, the more likely it is that you’ll get the data you want out of the tools and processes, and the more control you can impart to the process without incurring additional overhead. In fact, you can “disallow” check-ins that aren’t associated with an active project in a given state, owned by the individual attempting the check-in. Pre-transition commit hooks can be scripted to validate SCC meta-data against fields in the associated issue, ensuring that code is checked into the expected project on the expected trunk or branch.
Lastly, successful developers test their code. In bygone days, a development team could generate a package for a release and “throw it over the wall” to QA to test. The barriers between development and QA are falling like the Berlin wall, and the tools of today support continuous integration where a build fires off and unit tests execute whenever the SCC system recognizes a check-in. Integration tests are documented, automated and driven by tools used by both the development team and QA. Regression test suites are continuously updated to include validations from ongoing fixes to ensure that problems aren’t re-introduced. All of this activity is ideally transparent, and results are published real-time. In an environment like this, the motivation to generate good code is “built-in”. Processes and tools haven’t gone away, but we’ve succeeded in bending them to our will in ways that are extraordinary. These are interesting times, whether you’re a developer, QA analyst, configuration manager, or a business user…
Gratitude
My soon-to-be-ex-wife has been known to say “Gratitude is the hinge on which the door of recovery swings”. So true. An attitude of gratitude makes all things possible. Without gratitude, it’s easy to fall into the victim role, or any of the trillion other diversions from the path to recovery. We know the third step is all about letting go and letting God, and gratitude is the perfect place to start that journey. If we’re angry or resentful, we’re clinging and it is highly unlikely that we’ll make a decision to turn our will and our life over to the care of God. So for now, I’m letting go of the story, because it’s not about the story. It’s about the choice I make right here, right now. That choice is to be grateful.
Hello world!
May God give you
For every storm, a rainbow,
For every tear, a smile,
For every care, a promise,
And a blessing in each trial.
For every problem life sends,
A faithful friend to share,
For every sigh, a sweet song,
And an answer for each prayer.