Ideally, I Shouldn't Try to Live in an Ideal World

Think Different

noreply@blogger.com (Doug) — Thu, 26 Mar 2009 04:35:00 +0000

Personally, I'd rank things differently then the ranking given in the previous post.

Revenue for the quarter is as expected
Revenue for the quarter exceeds expectations by 10%
Revenue for the quarter are short of expectations by 10%
Revenue for the quarter exceeds expectations by 50%
Revenue for the quarter are short of expectations by 50%

And I'd only classify the first as success. They key isn't how much was achieved as much as how close to expecations was the result. To me, that's the difference between a short term and a long term view.

Rating Outcomes

noreply@blogger.com (Doug) — Tue, 24 Mar 2009 22:49:00 +0000

Let's for a moment say that you run a business (if you don't already). You have forecasted your revenue for the quarter. Now consider the following scenarios:

Revenue for the quarter exceeds expectations by 50%
Revenue for the quarter exceeds expectations by 10%
Revenue for the quarter is as expected
Revenue for the quarter are short of expectations by 10%
Revenue for the quarter are short of expectations by 50%

I'm willing to bet that if I asked you to rank these scenarios from best to worst, you'd rank them in the order I've presented them. I'm also willing to bet that you'd classify 1-3 as successes and 4-5 as failures. Feel free to comment if I'm wrong.

Expectations

noreply@blogger.com (Doug) — Tue, 24 Mar 2009 01:50:00 +0000

A failure can be defined as when expectations are not met. The less met the greater the failure. Conversely, success is seen as meeting or exceeding expectations. One way to avoid failure is not to have expectations. But then it is very difficult to imagine a worthwhile endeavor that does not have some form of attached expecations.

So the really short answer is that it is impossible to avoid failures.

Update: That is, it is impossible to never fail. There will always be expectations and success and failure is judged based on those expectations.

Failure

noreply@blogger.com (Doug) — Mon, 23 Mar 2009 06:56:00 +0000

The thing that has been bouncing about my head for the last few days is,

Is is possible to avoid failure?

The short answer is no.

The slightly longer, but still short answer is: no, depends on your attitude and yes.

To be continued...

Good Teams

noreply@blogger.com (Doug) — Fri, 20 Mar 2009 02:06:00 +0000

While watching a bit of basketball the other day, I heard a good description of the difference between a good team and a bad team.

A good team accepts that they worked together and are responsible for the good and the bad that happens to them.

A bad team is made up of individuals that take credit for the good and blame others for the bad. (Shall we call them egotistical finger pointers?)

Blame

noreply@blogger.com (Doug) — Wed, 18 Mar 2009 22:03:00 +0000

While I'm quoting people...

"It's not who's wrong, it's what's wrong. It's not who's right, it's what's right." - MIKE WROBLEWSKI

Responsibility

noreply@blogger.com (Doug) — Tue, 17 Mar 2009 00:27:00 +0000

Just got back from a ThoughtWorks' Quarterly Technology Briefing and was pleasantly surprised to see Jason Yip there. Best anology from Jason:

Not taking responibility for a problem is like saying the hole is not on your side of the boat.

Title Change

noreply@blogger.com (Doug) — Tue, 03 Feb 2009 21:15:00 +0000

I've changed the title of this blog, because I find it the old title (Experiments in Sofware Design) isn't so much what I'm concerned with now days. When I started this blog, it was more about design and practices. Now I find myself thinking about things more abstracted from programming, yet still very applicable to make sure that programming happens properly. Hence the new name...

Debugging in Eclipse across different JRE versions

noreply@blogger.com (Doug) — Wed, 15 Oct 2008 22:55:00 +0000

From time to time, we get issues that only occur with a particular version of the JRE. Setting a break point and then stepping into the JRE sources proved to be troublesome as the mapping between which JRE was being used and the JRE source was not correct. Fortunately, I've recently discovered the issue. While the runtime JRE was set to one version, the actual classpath had a different JRE. The key is to remember to also change the classpath to use the same JRE as the runtime JRE.

I keep forgetting this, so basically, note to self...

Brisbane JAOO - Conference Day 2 - Morning Keynote

noreply@blogger.com (Doug) — Sat, 31 May 2008 03:17:00 +0000

The morning keynote was given by Erik Meijer,Why Functional Programming (Still) Matters.

Creating software is all about abstraction, which is reducing information and retaining only relevant information. Unfortunately the industry has been abstracting the wrong details for the last 50 years...

There are 5 Dilemmas:

1) Useful versus Useless

I'm not sure I really understood the point Erik was trying to make here, but it was along the lines of the things that makes programs useful are the things that make them vulnerable to misuse, such as data as code and component interaction leads to XSS, buffer overruns, virus and BSOD.

2) Rich versus Reach

Flash, Silverlight and Java are rich (proprietary) whereas HTTP, HTML and JavaScript have reach (open standards). Whatever :)

3) Local versus Remote

Local is easy and remote hard. Local is what is taught in school. Remote is interesting and more like real life development. Erik defined attributes of local as:

compositional
sequential deterministic
implicit
synchronous
homogenous

and remote as :

concurrent
nondeterministic
explicit
asynchronous
heterogenous
noncompositional

4) Change versus Inertia

Geeks like to build cool things. People just want to get things done. Marketing tries to make people believe that the cool new things that the geeks built are the things they need to get stuff done.

Geeks p(success) = F(10 X improvement * Moore's Law)
People p(success) = F(perceived crisis / perceived pain of adoption)

see "The Change Function"

The fifth dilemma seems to be Erik's main point...

5) Pure versus Impure

Erik gives an example of some code (in C#?) that does a couple of queries including output that outputs in an order that is non-intuitive. The issue is that the code can be read as local yet the code is remote and the side effect of this is that things don't occur in the order that they have been coded.

Another couple of examples (C# again?) shows an unchecked exception happening beyond where it would appear it should occur and a file being disposed before it is used, again local versus remote.

The main point of all of these examples is that there are side effects occurring that are not obvious from the code, i.e. the relevant information has been abstracted away.

Erik continues highlighting side effects by stating that even object creation has side effects, i.e. two different heap spaces are set aside for two different objects of the same class.

Code has side effects which are not obvious from reading the code, that is the side effects of code are as important as the parameters and the return value. But you can't get rid of side effects.

Erik states that Fundamentalist Functional Programming is the answer (pure functions with explicit effects) where a functional language is defined as a language where functions are first-class citizens and given a function and a set of parameters, the function returns the same value ever time it is called with the set of parameters (equality-preserving, i.e no side effects). I believe it is here that he also makes the point that parameter evaluation should be lazy, but I have to admit that where this was mentioned or the importance of it was lost to me.

Monads allow the declaration of a functions side effects and he gives a few examples of what this means the mapping to and from functions with monads.

Then Erik considers whether or not normal programmers can understand what is required and can functional programs interact with legacy code. He gives some examples though all a little bit underwhelming in convince me that either is possible without much pain and gnashing of teeth.

He concludes by giving a litmus test for determining whether or not a language is a fundamental functional language and suggests buying a Haskel book and helping to persuade MS to produce a fundamental functional language.

While I found the talk interesting, it was rather unconvincing in its final conclusions for me. I'm in no rush to run out and buy yet another language book and I doubt I'll ever tell anyone what language they should implement. Erik's real crisis is just a perceived crisis and I doubt the industry would change to Haskel anytime soon based on the evidence from this talk. In the end, this talk just seems like an intellectual exercise to get people to think...

Brisbane JAOO - Conference Day 3

noreply@blogger.com (Doug) — Fri, 30 May 2008 10:05:00 +0000

Day three, pretty much the same as day 2, which is a good thing. I'll follow up later, but two snipets of the day.

Bob Martin talking about Clean Code: "Code in a try block is living in a fantasy world where nothing goes wrong."

End of the day chatting with Erik, Gregor, Patrick and Joe and then being invited out for dinner! (Sadly I was too tired to take up the offer :( ).

Brisbane JAOO - Conference Day 2

noreply@blogger.com (Doug) — Thu, 29 May 2008 10:45:00 +0000

Wow, what a wonderful blur of a day it's been. Reflecting back on the day feels like looking over a few days in time so much has happened. Two interesting and informative keynotes and six sessions all with good knowledge to take away.

If I had to pick one session as a favorite, it would have to be Erik Dörnenburg's and Gregor Hohpe's Software Visualization and Model Generation. Simple ideas that can have a big impact on helping to manage large amounts of data. Basically they presented a simple pattern for using different tools to help visualize data. I'll post more details on this and other presentation over the next week or so.

Brisbane JAOO - Tutorials Day 1

noreply@blogger.com (Doug) — Wed, 28 May 2008 09:41:00 +0000

So today was my first day at JAOO. And I loved it. I attended two vey good tutorials: Rebbeca Wirfs-Brock's The Art of Telling Your Design Story and "Uncle" Bob's "Advanced Principles of Agile Object Oriented Class and Component Design. Both presenters were engaging and definitely knew their subjects.

From the first tutorial, the key point was figuring out what to remove from a story to help more effectively get your point across to your audience. There were a lot of good points across the tutorial and good information that can be used beyond just telling a design story.

I really did enjoy the second tutorial. Bob is animated, full of energy and happy to digress slightly into entertaining and informative rants. He's completely shattered (in a good way) my view on OO modeling and the "is-a" and "has-a" relationships with excellent concrete examples. He gave us solid categorizations for defining problems with software designs. He made us reconsider what OO really means and I now have some interesting metrics to take back to our team to analyze the state of our codebase. Not to mention the design patterns he has for encouraging good design and fending off software rot. If I have some time and motivation in the future, I'll go into a lot more detail of what I learned from this tutorial.

Oh, and being in the same room with the likes of "Uncle" Bob, Micheal Feathers and Martin Fowler, I'm really enjoying it...

Better than simian-check

noreply@blogger.com (Doug) — Tue, 27 May 2008 06:13:00 +0000

Simian is great for helping to maintain code quality and enforcing the DRY principle, especially in a green field project. And while not as helpful, it can help to implement the idea of "making things no worse" in a brown field project. However, its goodness only extends in one dimension for a two dimensional problem.

A team can mandate that the number of duplications within the codebase shall be no more than some threshold. That's one dimension. But what about duplications that already occur below the threshold? simian-check does nothing to ensure that the level of duplication below the threshold doesn't entropy. Simian is good for legacy codebases, but there is plenty of room for improvement.

This is something I've been mildly aware of for several years now, but I haven't been actively trying to find a way to solve it until recently. I had some slack time and was feverishly working at refactoring our legacy codebase to reduce our simian-check threshold another notch. Having reduced the count by one, I took a quick survey of what would be required to reduce it by yet another notch. At that moment I half panicked half had a flash of insight (most like I had the insight quickly followed by a brief moment of terror).

If you've never had to play in a large legacy codebase, you may not have ever run into the situation I just found myself. Since simian had not been running on this system, there was a lot of duplication. The more the threshold was lowered for the simian-check, the more work (i.e. more duplications to be removed) was required to lower the threshold one more notch. And the increase in work is more than linear.

My insight was this; I had a finite amount of time in which to lower the duplication count. If I couldn't do all off the work within that time, the threshold would remain the same. It was quite possible that I could remove half the duplications and then return sometime later and find that I had double the work to do. While that's possible, it's not very probably. I had seen the second dimension to the simian-check. My fear from that initial thought got the wheels in my head in motion.

The solution is very simple. The simian-report is a an xml file, so I wrote a SAX2 DefaultHandler that was able to parse the number of duplications at the different threshold levels. Putting this into a trivial ant task then gave us a task to help make things no worse even at levels below what the simian-check was doing! Within the first week, the new legacy-check was breaking the build (where the simian-check would never have) and focusing the teams attention on how to make things better.

Scala

noreply@blogger.com (Doug) — Sun, 04 May 2008 01:39:00 +0000

I've been spending a bit of my spare time learning Scala. I like it because:

It compiles to Java bytecode
It can use any of the Java API's - the years of investment I have in them translates seamlessly to Scala development and I'm productive almost immediately
Functions are first class citizens of the language allowing for higher order functions leading to a more expressive language

It has a some other benefits, but I haven't fully learned the language just yet, so it's hard to say I like it because of things I haven't experienced.

The main drawback at the moment is lack of IDE support. I'm using the scala eclipse plugin, but it is primitive compared to the Java support I'm used to in eclipse.

The quality of the code you write today...

noreply@blogger.com (Doug) — Tue, 29 Apr 2008 00:57:00 +0000

... will affect your ability to write quality code for the new features you need tomorrow.

If you haven't been writing quality code, how can you expect to write new code with any degree of quality? I hypothesize that the affect of this isn't linear, but exponential.

No difference between permanent and contracting...

noreply@blogger.com (Doug) — Mon, 28 Apr 2008 10:22:00 +0000

I started out contracting for a long time until eventually moving into a permanent position. At the time, on reflecting on everything, I couldn't see any major difference between the two. I've always maintained there isn't a big difference in the long run.

But there is one thing I've just started to realize that I miss. That's the downtime (when there is some) between jobs. Now I take holidays, and even though I know I'll still have a job when it is done, I don't have the time to learn new technology like I would during downtime.

Holidays are for de-stressing and catching up with family. Downtime was the time to re-skill and explore. Or more likely, I had more free time to develop my professional skills and interests.

Ironic

noreply@blogger.com (Doug) — Mon, 14 Apr 2008 09:59:00 +0000

Seth makes a interesting point about something I've noticed for a long time. The main point that I find of value is:

It's just too long a ramp up time, too frustrating and too uncertain to be the best path to make a living.

But this applies to more than just writing a blog.

I believe (and live by the idea) that only the people truly passionate about what they do seem to be the ones that do the best. The ones that are famous/wealthy/successful are the ones that didn't set out to be famous/wealthy/successful. The passion gets you over the ramp up time, the frustration and the uncertainty. And most importantly, the passion gives you the drive to focus on doing what is best for your passion and not necessarily for you ego.

Personally, I'm passionate about programming to provide value. I'm passionate about quality. I'm passionate about eliminating waste. I'm passionate about flow. I'm passionate about chasing perfection.

And I do love irony at times...

What to do...

noreply@blogger.com (Doug) — Thu, 10 Apr 2008 02:59:00 +0000

Now that I've got the Google Apps account, I'm struggling a bit about what to do with it. I thought about writing a blog app and blogging to that as well, but someone already beat me to that. I have a few ideas, but they are all incomplete and seem to serve no useful purpose. I'm open to suggestions (hint, hint, comment, hint, hint).

Learning Python

noreply@blogger.com (Doug) — Thu, 10 Apr 2008 02:52:00 +0000

Thanks to the Google Apps account, I'm now learning Python (to some extent). The first important task when learning a new language is learning to read errors. After a few, I think I know what the interpreter is trying to tell me when it's not happy. But the first time is always the funnest.

As a complete Python newbie, I initially missed the difference between:


class MainPage(webapp.RequestHandler):
 def get(self):
   self.response.headers['Content-Type'] = 'text/plain'
   self.response.out.write('Hello, webapp World!')

def main():
 application = webapp.WSGIApplication(
                                      [('/', MainPage)],
                                      debug=True)
 wsgiref.handlers.CGIHandler().run(application)

and

class MainPage(webapp.RequestHandler):
 def get(self):
   self.response.headers['Content-Type'] = 'text/plain'
   self.response.out.write('Hello, webapp World!')

  def main():
   application = webapp.WSGIApplication(
                                        [('/', MainPage)],
                                        debug=True)
   wsgiref.handlers.CGIHandler().run(application)

10 minutes into the lexical spec and not only did I get the error here, I got a far better and first hand understand of Python. Now the task is to keep learning...

Google Apps

noreply@blogger.com (Doug) — Wed, 09 Apr 2008 08:11:00 +0000

Don't know if I was looking or Google has been generous, but I've got a google apps account. The reaction was, "Quick, grab a new toy." Followed by (ask requesting it), "Um, what am I going to do with this?!?". Apparently, the first thing I'm going to do is learn Python (which doesn't appear to difficult, apart from the lack of semicolons :)).

Estimations - Best, Expected and Worst

noreply@blogger.com (Doug) — Thu, 06 Dec 2007 10:34:00 +0000

One of these posts I'll stop mentioning Dave Thomas, but until then...

Another thing that he mentioned was how to give estimates. Nobody should give a single point estimate. No risk factor is involved. But given a best case, expected case and worst case, it is quite easy to see what is risky and what isn't. With this in mind, we spent quite a few hours today giving high level estimates for our current work using these three points. (Work that we hadn't estimated but had planned to sometime this week. Isn't it nice how things come together sometimes...) I think everyone got something good out of it and our estimates feel a bit more accurate and considered.

To be honest, as a developer, I feel horrible when I miss an estimate, whether it is longer or shorter than expected. But with three point estimates, as long as we hit the range and are good about being close to our expected I don't think I'll mind missing our expected estimate (which is the only one we gave in the past).

Feeling the Rhythm

noreply@blogger.com (Doug) — Wed, 05 Dec 2007 11:19:00 +0000

When we've been writing tests lately I've caught us occasionally not feeling the rhythm. It's more obvious now and I'm actually stopping and looking for a red bar. And I haven't found it on a at least 2-3 times over the last few days.

A test without the Red Bar is a waste of everyone's time and instills false confidence/trust that will get shattered eventually.

Dave Thomas sound bites

noreply@blogger.com (Doug) — Wed, 05 Dec 2007 11:11:00 +0000

Dave Thomas (the SmallTalk one and not the Ruby one) gave a very interesting presentation tonight with a lot of good information in it. Two things really stood out for me:

Best Wrong Way
Stories without Acceptance Tests are wishes (I may be paraphrasing slightly)

Best Wrong Way means that today we are doing our Best Wrong Way and tomorrow we will find a better Wrong Way. There is no Best Right Way (just like there are no Silver Bullets). A lot like focusing on making things no worse instead of trying to always make things better.

I think wishes speaks for itself.

Almost an Agile conference in Brisbane

noreply@blogger.com (Doug) — Tue, 04 Dec 2007 21:38:00 +0000

I mentioned Agile conferences in Brisbane before (specifically the lack of), but now it looks like there will be something with possibly an Agile track at the end of May, 2008. Thanks to Dave Thomas (not the pragmatic one, the other one :) ), we'll be seeing a major conference with a definite technical focus in Brisbane. Yay! Details of speakers and tracks should be updated some time in January.