| Ken's profileTempus FugatePhotosBlogLists |  Tools  Help |
They're ComingThis past week, I flew in from India and have been wicked busy
preparing for a short vacation with my babies. Finally, the day
arrives. My little ones fly in today and we're going to visit the theme parks and the beaches and just go crazy! This is so what I needed. So for the next couple days I'm out of pocket, but I polished a couple new entries up for later. I hope your spring break is as fun as mine is going to be! Time Whose Ideas Have ComeThis past couple weeks on the road in India have been remarkably
productive. Not just in terms of raw accomplishments but in terms of
setting up capability for future accomplishment. Sometimes I think we
forget that often it is only investments you can make today, not
concrete accomplishments. A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of idea.I find myself facing this dilemma repeatedly in almost every aspect of my life. Conversations about work/life balance and relationships inevitably turn to my own inability to invest in myself as well as should. Which is ridiculous against the stark contrast of the overwhelming volume of advice and encouragement that I give to others. Virtually every encouragement, every response, every nudge I give to others is rooted in that basic concept: invest in yourself first. And yet, I fail, and fail spectacularly. One would think in all my study and thinking, in my continual pursuit of perfection around me, at some point I would work on the lack of perfection inside me. Of course, could I cure that cancer would I take away the laziness that so motivates and inspires much of my creativity? Who is to say. It is purely part of my pathetic reason and excuses nothing. Perhaps some day, in some way, I will find the means to force the change even in my own deliberation. Don't hold your breath. Trying To Get A NutThis past week I had a very interesting conversation with a friend over
breakfast. He is one of those quick minded people who is constantly
analyzing the world around him as it relates to himself. Unlike most he
does this consciously, deliberately which is a trait I much admire. During this conversation the subject of motivation came up. Why do we do what we do? When pressed to me I had to confess that I believe that life is about service. Therefore my motivations are my service to others as that will indirectly be my service to my God. As is the case with many good conversations, my thinking didn't end when the conversation did. I continued to ponder whether my answer was complete, and if my walk in life lived up to my talk in the conversation. Naturally, my mind bent towards money. In my heart I know that the motivation for giving money should be based on my need to respond to God's gifts, not on the need of someone else to receive my gift. My motivation for giving should not be a church need or another need even; no matter how worthy that need might be. The needs might be totally legitimate, but that isn't the point. They are just not supposed to be the motivation behind the giving, the service, the commitment. Giving and service should be motivated out of the abundance of blessings that God has bestowed on my life and my ongoing desire to respond by giving back to my God with my whole life. If gratitude is sincere, it should impact me; there should be a cost. If it does not, then you aren't really acknowledging that you have been impacted. You are dismissing the value of the blessing when you respond without equal measure. Since I've been given life, my response must be my life! I once heard the story of a mother who took her young son to church. As they were leaving, the mother shook the hands of the preacher, and then she said, "Caleb, shake the preachers hand." Johnnie didn't put his hand out. The mother asked again. He still didn't put his hand out. Then she said again, "Caleb, shake hands with the preacher." At that, little Caleb opened his fist and out rolled the three marbles that he had been holding on to tightly. Little Caleb didn't want to shake hands because he didn't want to give up his marbles. How often do you give up your marbles? Have you ever seen a raccoon trap? They use a basket with tiny hole in the top and they put food inside. The raccoon will reach in and grab the food, usually nuts, but won't be able to get its hand out holding the nuts. The raccoon will stay there holding the nuts because it won't let it go even when the trapper comes. Are you willing to let go of your nuts? You Kissed BackHouse just keeps getting better and better. They manage to take the depths we sink to and make them real and tangible. Cameron comes in gives him a letter of recommendation to sign, which he does without reading but with proper vhim. Then when he asks her if she really wants to leave, she doesn't say anything, she just slowly approaches and kisses him. It is passionate and amazing. My heart stopped for just a moment. But as all fantasies do, this one ends poorly. She was really trying to stick him with a needle to sample his blood, and the kiss was just a cover. Naturally, House isn't fazed, but Cameron is definitely taken back. Not for being caught but because... Cameron: You kissed back.Such an amazingly realistic exchange laid bare and exposed like that. It was so palpable you could cut it like butter.  300Wow. You would think by now I'd have grown immune to the 17 hour flights overseas. Nope. They still knock me over. This weekend before I flew out I got a chance to see the new movie: 300. Surpassingly tremendous. Utterly fantastic. Incredibly amazing. 
This movie is everything you want in a great story and more than you can ask for from a great movie. There are evil villains, larger than life characters, men of iron character, and women of fierce resolve. The dialog is spectacular in places and over the top in others. The production quality is simply phenomenal. The soundtrack leaves you pumped, breathless, and awestruck. The story, while told superbly, leaves you amazed to consider those on which the story is based. Sure they take license in the telling, but the events at the heart are no less moving, inspiring, powerful. In the course of a few hours my whole standard for movie excellence was unmended and unmade. If you haven't seen it...go now. The Business of Software DevelopmentThere
was an interesting exchange of ideas I witnessed today. The crux of
the issue was someone trying to understand the benefits of the Model
View Controller (MVC) pattern as socialized by Microsoft. Having some
interest in the subject, I watched it grow from a comparison with Event
Driven Architecture (a complete misnomer) to contrasting with Model
View Presenter (a new flavor of old idea), to just plain batting around
the technical merits of various implementations of these common
concepts. As one person after another jumped on the band-wagon,
virtually everyone had something insightful and technical to say. But
none of them brought it back to the business problems. This troubled
me as it was indicative of the way we forget that we are in the business of software development. Not just doing software development. Here was my contribution: -- On many systems we see that there are really two types of logic often treated as the same while they are very different. The first type are UI rules which I’ve seen loosely defined as how we paint screens and provide rich user experience. Then there are business rules which I’ve seen loosely defined as how we manage the data and interactions with the services or repository of the system. Because we tend to not treat these separately, we also tend to see them tied very closely together in designs and implementations. This presents multiple challenges such as making it harder to encapsulate logic and reuse it and the breadth of knowledge grows (i.e. you need to know UI programming and API/data model programming). MVC is one pattern that attempts to address these challenges, and there are many other patterns that address them as well. Get ready for the twist... On projects with lots of UI rules that are tied closely with lots of business rules, these challenges are compounded. Especially when you consider how we can go about testing all that intertwined code. There is lots of anecdotal evidence to support that testability remains one of the biggest challenges on projects with hundreds of interfaces. When looking at the cost/benefit of different designs for large applications we have repeatedly seen cost of testability to be one of the single biggest factors in terms of monetary impact. We can argue a design on technical merits all day long and have differing subjective opinions, but we are in the business of software so we have to be able to quantify the impact of a design in terms of cost also. My personal experience has found that the cost to test is one of the most easily overlooked. Having no one else on this thread bring up the subject as a crucial factor sort of reinforces my point. Being able to write automated tests is imperative when we have hundreds of UIs. Separating the two types of code means it is significantly easier (read: less time, less custom skill, less money) to craft the thousands of test cases required and the controller logic can be run without additional user windows and workstations. This is because the test cases are standard API code, not rich UI code. In these cases the UI acts as the test without providing an actual UI, instead it just executes the controller to test the business rules. It doesn’t just make the tests of business logic easier to write, maintain and reuse, it can actually increase code coverage allowing us to get to exception areas of the code that default UI logic would prohibit. For example the UI rules for the initial type of application being constructed don’t allow certain behaviors. However, the controller must be able handle them so that other types of UIs can also be crafted. If we only test against the UI directly (read: the actual UI we are delivering to the users in the first release), we won’t test those hard to reach places. If we don’t test those hard to reach places then when we finally do build the second or third kind of interface and it reaches there, we find new bugs in code we thought was tested well. Automating the controllers allows us to minimize this risk. To sum up: yes the MVC-class of pattern allows us to encapsulate logic, and yes it can provide significant reuse of code, and very definitely yes it can be argued as good design. But in business terms, we often forget to make the leap to testability as a primary motivator when time to quality gets really small. Too often we swap our opinions on technical subjects from our ivory towers without considering the business factors that should be influencing us. -- Whatcha think? SundowningThis past week was rough. Saturday was tough. But Sunday, blessed Sunday... I got to catch up on something I've been putting off far to long. Along the way I was able to learn some new things that will prove very handy in the future. There was sleeping in, and lazing around, and more than a little light reading. But the best part was the beach. Watching the sun come from out of the clouds to dip into the water all ablaze was definitely the highlight. 
By now I have learned to steal time as time allows. Even if I do a poorly job of it. A good friend inspired this adventure today; maybe that was all I needed. To be reminded that friends fill you up way more than they take away. Next time I leave my shoes at home... Stomping GrapesSomeone who works for me recently was charged with doing some work on a
system that many people use for the project on which we were working.
He came to me with concerns on how to proceed. He wasn't sure how to
set expectations to the team about the work he was doing. He was
struggling with how to layout his work because he was concerned with
impacting others. Keep in mind, his work is absolutely crucial to the
forward progress of the entire team and as such has far reaching
impact. Specifically, he was proposing to create multiple versions of
the system and play a shell game of moving people from system to system
in an attempt to minimize their impact. The following is a much edited
version of the email I responded with: ---- The proper way to follow an Adaptive Approach is to keep one and only one reference or definition for a thing. In this case that is your application. If that impacts other work we are doing on the system, so be it. Work fast. One of our basic principles is that the overhead used in trying not to impact other people slows us down. This slow down costs a lot and the amount of impact avoidance gained is rarely enough to warrant the expenditure. As such, if you need to make changes, then by all means make changes. If that impacts people, so be it. Work faster. I will give you my best advice that you have heard before and will doubtless hear again from me. Think in terms of a single build. A single process. A single copy of code. A single version. A single Application. And so on. When you think about "old" versus "new" it skews your ability to focus on the work. Instead you spend mindshare on preservation of work, or juggling conflicting requirements. Whenever I hear someone in a conversation about setting expectations start to say "What we were doing…" or "Before we did it like…" or anything that doesn't speak in the present or future tense I mentally shudder. They have just lost points with me and I make a mental note that their stock price is sinking. That is because they are effectively wasting the time of everyone in the conversation. Like ripping a bandage off, or breaking up with someone, you need to just do it quickly and for heavens sake do it all it once! One of the quickest ways to get into an Adaptive Approach is to forgo chronological labels like old and new. As the Highlander would say, "There can be only one." It means you impact people more often, but working in isolation is a myth of software, not reality. You will find that software development (real software development) is a social activity. It’s sort of like stomping grapes. You can try not to get any on you, but you'd be really missing the point as well as the fun. Wash your feet, wear white clothes, and embrace that the mess is going to get everywhere for a little while and your clothes will never be the same. Enjoy the stomp, it makes better wine. |
|
|
