f3yourmind

Artists have muses.  Muses are their creative inspiration.  The Greeks also called it a daemon – that mythical thing that gave magical creativity.  It’s actually their genius spirit that helps them when they’re stuck in a metaphorical tight corner.  Same thing, I think.  So when did we stop having geniuses and became geniuses?

I think I am actually searching for a muse.  Something that will be my creative genius.  I gave up trying to be a genius a long time ago.  Now I just want to learn from those that are better than me, whatever the context.  Maybe my muse is the sum of every engagement with the genius in each person with whom I work and live.

I never liked the words pilot nor proof of concept.   I have been through many pilot projects and proof of concept as projects or in projects.  Although the intention is well understood by everyone at the very beginning, by the time we reached the end, there almost always seems to be confusion about the purpose and next step.  Now I don’t even seem to know the differences and intentions anymore.  Even though everyone seems to know that they are different, they receive the same miracle software expectation.  It’s an execution confusion issue.

But I think the main reason for pilots and proof of concepts is to get feedback.  Spikes do the same thing too.  You know you’re seeking enlightenment when you start saying “I don’t know … enough…” or “It depends…” or “What if.” Whenever we work with a new domain or a tricky part of an application, we are searching for feedback, not miracles.  If you practice TDD and do exploratory testing of concepts that are not 100% clear in design and even understanding, then you know what I mean.  Perhaps we must just drop the grand classification labels and our response should be something like “Well, let’s explore this tiny bit and see what happens” or “Why don’t we try out this idea by doing …”.

So we do proof of concepts and pilots all the time.  It’s just that I hate searching for miracles but I like feedback which helps me change the probabilities of certain of things happening.  And I like it to be part of my workflow.  Exploration gives me feedback and increased understanding that leads to more exploration.  I hate it being a milestone on a Gantt chart and when that milestone is a common point in critical execution paths for the project, then I know, for sure, someone was actually looking for a miracle.

If you are somewhere on the agile adoption curve, then drop the Gantt chart.  Now you’ve just removed the shrine for miracle worship.  There are no shortcuts to enlightenment, just feedback with every step.  Success depends on how you absorb and react to that feedback.

I see many people freak out at the mention of any change.  I often do that too.  Why?  Because it forces me out of my comfortable existing neural wiring.  Now I try to view change as a contextual adjustments and a little bit of re-wiring for comfort sake.

Hmmm, as I age, I think the slight contextual shifts that I go through now feels less like the massive catastrophic continental shifts.  Much nicer.

Peter Hundermark has a nice summary of the talk on Agility at Scale that Scott Ambler did in Cape Town a few weeks ago.  And Scott had the courtesy of straightening out some thoughts on Peter’s blog as well.

Padding End Dates. End dates exist because of our immense desire for closure.  We cannot tolerate the thought of not knowing when something comes to an end.  So we would rather stick in a fake end date than no end date.  Are you prepared to stick an end date on your life, just so that you can create a finite sense for someone else?

Optimizing the whole. For me “whole” means everything, your workflow, your thinking, your architecture, your code, your communication, … everything.  But just drop into the code bit for a moment.  The reason TDD works is because it gives you feedback quicker.  It is not about the red-green-refactor process alone.  You have to be agile in your code and design too.  And linear problem solving results in linear code styles and mindless red-green-refactor results is not agile unless you are 100% immersed in the moment of exploration and discovery.  Overall, I think optimizing the whole, getting rid of wastage, lean, etc is all about finding the right balance – at that point in time, in that context.

BDUF. How much of upfront design is big design up front?  It depends on the context and the principles on which your software development is based and also who is affected by the software that is produced.  I like the phrase “little too much design up front” and “little too little design up front” which I picked up in this post by Kent Beck. (Please don’t acronymize that!).  That particular post was simple and extremely profound view, for me at least.

Just when I thought that I am making progress, I feel like a noob again.

The unfortunate human characteristic in all of us is that we like rules when we’re in a new and unfamiliar situation, and hate them the moment we think we are experts.  The problem is that rules are great for creating concrete things.  If you want to build this then: do a, then b, if you have a c then do d otherwise do e.  But it does not work with creating abstract things.  And software development is all about building abstractions.

In the past few weeks, I’ve had a few instances where I realized that some people were,  basically, asking me for DDD rules – steps for building an aggregate, when and how to use the specification pattern, etc.  There are no rules for the noobs for these things.  But I think I can constrain the environment so that the noobs can focus a bit more intimately with these aggregates and specifications.    One rule I put down was “When working with the following … don’t work outside of this Java package”

Essentially, my proposition is that rules for noobs should constrain the learning environment, not the subject being studied.