The concept of “importance”, seems relative to our own perceptions of reality; a circular train of reason that if removed leaves everything without explicit meaning, just that it exists. And by that logic, art, beauty, etc all fall into that same category: yet another perceptual filter. Beauty exists only in our minds, perhaps so that we may persist in a world whose meaningfulness may be of our own design.
And after you’re gone — perhaps the world is slightly shaped so that your perceptions may persist for others to experience
** and why does my iPhone take better pictures than my camera?
… you believed you knew what you wanted. You achieved what you wanted only to find that you were still not satisfied. You simplified, looked inward, and understood that which drives you. Simplicity and a designed life were only goals you set and achieved. Achieving these goals results in the same stagnation. Your life is a series of goals towards some end, some ideal, something before death.
You yearn, again, for something different. Anything different. Your own advice and that of countless others consoles you. Do you merely set and attain goals over and over until you die? The futility of this process is… futile.
Your past can remind you of where you want to be if you get too far off course. This is where it begins. The simplicity is needed in order to build the momentum needed to achieve something larger than yourself. Your ideals guide you in action towards larger goals that shape this world. Where it begins — something big — the world at your fingertips.
No one seems surprised to hear that most IT projects fail. One would think that the increasing number of delayed and over-budgeted projects would illicit some kind of existential crisis on the part of IT professionals. Many projects sustain on life support missing nearly every milestone, either to eventually die or find some inkling of success (albeit at a cost that no one would have agreed to at the start of the project). Repeating the same mistake over and over it points back to one thing: requirements. What the hell is this thing suppose to do?
Arguably, there are technical issues, people issues, and various reasons IT projects fail. There are however, necessary components to success (conversely, guaranteed failure) and all of them start with requirements. And I don’t mean the kind of vague nonsense requirements espoused by analysts (e.g., “make it work with Siebel”), I mean the rigorously defined requirements that most of todays analysts and IT consultants couldn’t write to save their lives.
I have been apart of enough projects to have seen the failures and successes that are common in this industry. Examining the failures there is a common theme: lack of good requirements. Not lack of documentation, not lack of specifications or attempts at requirements. Attempts were made at requirements in almost all cases, but failures persisted in every situation where the requirements were vague, ill-defined, or unrelated to the business needs.
I have worked on such gems as “build an end-to-end data architecture”, or “add live flash streaming”, or “integrate at&t”. These type of things always missed their deadlines and expectations. It’s surprisingly difficult to meet expectations where none were set; in the IT world anything delivered in that situation will be wrong and likely your fault. Worse, if the management is poor then the lack of requirements slides downhill onto the engineers who didn’t think it was their problem.
The problems can be seen a mile away. The difference between the professional software engineer and most of the developers occupying IT roles these days is that the professional engineer will not commit to any deadline without clear well-defined requirements. Any amateur can promise an “end-to-end data architecture”; but the professional will make no promises without requirements that he or she can work from.
In many cases, just the exercise of defining requirements would lead to the realization that the project isn’t feasible and in some cases doesn’t even need to exist. Better to know up front that your project will fail than wait months or years later, right? Not if you want to keep your job, but yes, if you want to work on successful projects.
Having well defined requirements will not ensure success, but it avoids a guaranteed failure.
Managing Success and Failure
Most IT projects like to track risks, but where is the failure tracking? Perhaps it’s too negative to go around tracking how a project could fail. Call it Success Tracking so as not to offend ‘the law of attraction’, but a clear definition of success and a scientific approach to understanding how the project could fail would save most doomed IT projects.
Without well-defined requirements this exercise is difficult if not impossible. How do you define success or failure if the requirements are not rigorously defined? Without an understanding of success your left only with failure.
Yet another tried and tested method for killing a project is a weak or non-existent QA process. There is no panacea to software development woes, but a QA process is a necessary component to success. Further, QA is impossible without well-defined requirements. Yet in many IT organizations there are QA teams working tirelessly to assure the quality of products without any clear requirements. What kind of quality are they assuring? What does it mean to pass QA without a requirement? It’s like a scientist doing a test without a theory…
Any amateur can toy with software to assure that it works the way the developer told them it works. A professional QA engineer follows the same guidance as the professional software engineer: they will not commit to assuring the quality of a product that lacks a well-defined requirement.
IT projects require well-defined requirements. IT professional wishing to avoid the same repeated mistakes will formulate requirements before committing to dates. As an engineer, I am happy to work on R&D in the absence of clear requirements and with the understanding that there is no date and no committed deliverables in that phase. In most organizations this can seem an impossible feat, but this is where we separate professionals from amateurs.
The world, to me, is a spectacularly confusing and amazing place. I am, admittedly, wildly ignorant to anything outside of my own reality; we all are, save God-like intelligence on the order of omniscience. My ignorance is to such a degree that I don’t even know why I exist and I’ve yet to meet someone who does. The “fundamental question” and we don’t even have an answer!
So, we’re blindly cruising through life with some “feelings” about what we should be doing and from what I can tell there’s a bunch of other people equally clueless about what they’re suppose to be doing. We seem to be born trusting these other people, and over time learn to distrust them (often for good reasons). What’s worse, I’m not even sure what those words mean: to trust or distrust a person…
It seems to me that you don’t “trust” another person, you trust your expectations of that person. That is, that the person will act the way you thought they were going to act. In that case, “distrust” is when you are expecting things from someone where you have knowledge that they will not (or refuse to) comply to your expectations.
Our expectations are often based on those same “feelings” and can even include moral judgments; some notion of a perfect or right way of acting. Our expectation of perfection yields distrust in the world around us.
I would argue that while we have a desire towards perfection we would be silly to expect perfection (and breed distrust). If we release our expectations of ourselves we are free to pursue perfection while maintaining ultimate trust in ourselves, and the people and world around us. It then forces the burden of trust onto the individual, trust becomes a matter of learning and knowing rather than expecting.
In other words, my trust is only a measure of how well I know… my distrust is only a measure of how wrong I was in what I thought I knew.
When I got home today there was a package at my doorstep that appeared like a black duffel bag. It contained instructions to cut open the bag.
As I opened it slowly expanded. A little less dramatic than the memory foam mattress that I ordered but it was interesting as this thing grew bigger and bigger.
Apparently it takes 48-72 hours for it to properly expand to its full-size after being compressed for shipment. Memory foam is awesome! Eventually it looked like this, albeit apparently not yet its full-size. Perfect for enjoying the view!
There’s a few other items on order, comfy chairs, and some coffee tables. Zen-like simplicity to sit down to a good book, draw, paint, work on a laptop, or just sit quietly over food and wine. Whether we choose our own design or just accept what was given it effects our every thought and every action. Our lives often are as malleable as my lounge cushion; out of the bag it was born in it expanded to full-size, and ironically can no longer fit in the old bag!