Logan's Rings

Quote of the Day

2012-01-09T21:38:00.000-08:00

To make things more complicated, the actual objects and classes that participate in a pattern almost always participate in other patterns at the same time. Focus on it one way, and it looks like one thing; change your focus, and it looks like something else. - Allen Holub in Holub on Patterns, Learning Design Patterns by Looking at Code

Goals 2012

2012-01-05T19:33:00.000-08:00

I'm getting an earlier start on my goals this year. I'd like to focus on my development skills primarily, but continue with problem solving.

So, in 2012 I will ...

1. Become a Certified Spring Professional
I've taken the training, read a couple of books and written a small web app in Spring so this should be doable in the first part of the year.

2. Read 6 software development related books
I've already got that many in my "to read" stack and I'll continue with the Wingdings book club.

3. Convert my "broken toy" library app to Ruby
I been wanted to get started with Ruby but I got sidetracked with Groovy and Spring.

4. Create a new "broken toy" app to help me keep track of the anniversaries and birthdays of my family and friends
This is one that I didn't get to last year.

5. Write two blog posts a month
This is a bit conservative based on last years total, but I'd like to spend more time on my skills.

6. Take some sort of multi-day software development training
This will be a reoccurring goal.

Goals 2011 Review

2012-01-05T19:08:00.000-08:00

Well, it's Goals Review time again! I had 5 stated goals for 2011...

2011 Goal 1: Read 5 software development related books

I was a little less ambitious with books in 2011 but that proved to be unnecessary. I joined a book club and that helped to push my total to 11:

The Design of Everyday Things - Donald Norman

Driving Technical Change - Terrence Ryan

Exploring Requirements: Quality Before Design - Donald C. Gause and Gerald M. Weinberg

The Inmates Are Running the Asylum - Alan Cooper

Java: The Good Parts - Jim Waldo

Pragmatic Thinking and Learning - Andy Hunt

The Psychology of Computer Programming - Gerald M. Weinberg

Rest In Practice - Jim Webber, Savas Parastatidis, Ian Robinson

The Soul Of a New Machine - Tracy Kidder

Spring In Action, Third Edition - Craig Walls

Working Effectively with Legacy Code - Michael Feathers

2011 Goal 2: Convert my "broken toy" library app to use Hibernate and Spring

Yes. I created 2 new projects: 1 based on Hibernate, and another based on Spring and Hibernate. I enjoyed learning about the abstractions in these frameworks and I especially enjoyed removing much of the boilerplate/plumbing code I previously wrote. I feel like I've just scratched the surface though, especially as I read the Spring In Action book - each chapter gave me new implementation ideas.

2011 Goal 3: Create a new "broken toy" app to help me keep track of the anniversaries and birthdays of my family and friends

Nope. This will have to be carried forward into 2012.

2011 Goal 4: Write two blog posts a month

Looks like I had a lot to say in 2011, as I created 61 posts! That's almost double my total from 2010. A couple of my favorites:

2011 Goal 5: Take some sort of multi-day software development training

Yes. I took the Core Spring course, and attended the Uber Conference.

One of my unwritten goals for 2011 was to continue pursuing a career that feeds my passion for problem solving, and I was able to further that goal by starting a new developer position.

I'm happy with what I was able to accomplish in 2011.

Exploring Requirements: Quality Before Design

2011-12-21T22:10:00.000-08:00

Exploring Requirements: Quality Before Design by Donald C. Gause and Gerald M. Weinberg is about "the requirements process--the part of development in which people attempt to discover what is desired." It's a comprehensive look at the process and the ubiquitous ambiguity that makes it extremely difficult and error prone. The book, over two decades old but still relevant and practical, presents tips and tools to ensure quality requirements.

The book will change the way that you look at requirements. It uses subtle humor and common sense to present and reinforce ideas. It's not a technical book and has something for everyone involved in product development.

The book is full of simple but important points:

Development is the process of transforming someones desires into a product that satisfies those desires.

The art of requirement process is not so much to provide answers as to raise new questions.

Instead of trying to compete ... on a feature-by-feature comparison ... identify the functions that will be needed to compete.

No single failure of requirements work leads to more lawsuits than the confident declaration, " No sane person would do that!"

Almost any real project, no matter how well planned and managed, contains a certain amount of hacking, because the real world always plays tricks on our assumptions.

The book is good at pointing out some of the more subtle parts of the process. For example, the types of requirements decisions:

Choices - made directly and consciously
Assumptions - made unconsciously through bias, error, or lack of information
Impositions - forced by law, custom, or higher-authority

The requirements process begins with ambiguity. Gradually the ambiguity is removed, clarified, and/or constrained. Even though not all ambiguity can be removed, at some point "you decide you have enough agreement to move on into the design phase." This book will help you confidently deal with ambiguity and move on.

The Inmates Are Running the Asylum

2011-12-20T21:02:00.000-08:00

Alan Cooper is one of my favorite writers because he forces me to think, and think, and think. I reread his book The Inmates Are Running the Asylum because I'm looking for better ways to develop and this book is full of better ways.

The book's premise is that software development is broken because the technologists are in control. Not because the technologist have seized control, but because the industry has abdicated to the programmers the responsibility of what to develop:

In the past, executives assumed that interaction design was a programming problem and delegated it to programmers who diligently tried to solve the problem even though their skills, training, mindset and work schedule prevented them from succeeding.

The intractability of the software-construction process - particularly the high cost of programming and the low quality of interaction - is simply not a technical problem. It is the result of business practices imposed on a discipline - software programming - for which they are obsolete. With pure hearts, the best of intentions, and the blessing of upper management, programmers attempt to fix this problem by engineering even harder. But more or better engineering cannot solve these problems.

Programmers are not given sufficient time, clear enough direction, or adequate designs to enable them to succeed. These three things are the responsibility of business executives, and they fail to deliver them for preventable reasons.

We can create powerful and pleasurable software-based products by the simple expedient of designing our computer-based products before we build them. Contrary to the popular belief, we are not already doing so. Designing interactive, software-based products is a specialty as demanding as constructing them.

The book's theme is that interactive products need a specialized design process and that the quality of software will improve by focusing initially on interaction design, which is not the same as interface design:

...interaction design refers to the selection of behavior, function, and information and their presentation to users.

[Cooper] prefer[s] the term "interaction design" over the term "interface design" because interface suggests that you have code over here, people over there, and an interface in between that passes messages between them. It implies that only the interface is answerable to the users' needs.

Interaction designers work from the outside in, starting from the goals the user is trying to achieve, with an eye toward the broader goals of the business, the capabilities of the technology, and the component tasks.

Things important for an interaction designer: a strong understanding of what programmers actually do, understanding of interaction design principles and methods, along with a taxonomy for understanding their users.

This book is one of my all-time favorites. It is riveting, entertaining, informative and thought-provoking.

The forwards (there are two) are excellent at setting the context for the book and should be required reading for everyone in the software development field.

My favorite chapter is the first, Riddles For the Information Age, which explores and answers the question of what happens when you cross a computer with anything else.

The Customer Isn't King

2011-12-16T21:27:00.000-08:00

In The Purpose of a Business is NOT Customer Value Jurgen Appelo presents an interesting contrarian view:

Most fads and panaceas ignore that a business is a social complex system. It’s purpose is not to satisfy only shareholders, or only customers, or only employees, or only the local community.

A business must satisfy everyone!

Java: The Good Parts

2011-12-12T21:16:00.000-08:00

Java: The Good Parts by Jim Waldo is an easy read and I was able to complete it in multiple short sessions. I like and agree with the author's description of the intent of the book as "not to teach you completely new things, but to remind you of things that you already knew but may have forgotten, or to get you to see things that you had already thought about in a new light."

Because the author is a Distinguished Engineer with Sun Microsystems he is able to provide some interesting context as to the why's and how's of Java.

The book describes the types of projects that Java is good for and details the following "good parts":

The Type System
Exceptions
Packages
Garbage Collection
The Java Virtual Machine
Javadoc
Collections
Remote Method Invocation and Object Serialization
Concurrency
The Developer Ecology

I especially like the chapter on Concurrency and the author's "gentle introduction to concurrency in the Java environment". Some food for thought:

Concurrent programming is the next frontier for languages and software engineering. Because of the advent of multicore systems, those of us who used to be able to ignore concurrent programming will no longer have that option. We are going to have to understand concurrency, and over time, we will no doubt invent idioms and practices that will make the programming of concurrent systems easier and more stylized. Until that happens, though, it is good to have a language and environment that you can trust to do the right thing if you have written the right program. Java may not have the ultimate answer to writing with multiple threads, but it has an answer that you can use to your advantage to deal with the new chips. That by itself makes this one of the good parts.

Why Software Projects Collapse

2011-12-12T21:06:00.000-08:00

In Sowing the Seeds of Failure: Understanding Why Software Projects Collapse Robert N. Charette takes a look at software project failures, including Denver Airport's failed baggage handling system, and offers sage advice for avoiding future failures.

The article is concise and makes some excellent points:

Any software project can be make to be late, over-budget, and technically unsound by simply not providing the requisite time, resources or specifications. There is no complicated trick involved - one out of the three will suffice.

Virtually all large software projects are unprecedented - meaning they have never been done before. They are in fact existence proofs, with high likelihoods of failure. Successful projects are always aware of this.

...software is a means to an end, and not the end itself...software is being used because there is no other way to accomplish a project's objectives at a reasonable cost, in a reasonable period, with acceptable performance and reliability, and the flexibility to grow...software is in effect the choice of last resort

In failed efforts, developing the software is frequently regarded by key decision-makers as not particularly difficult, from either a technical or managerial perspective.

Not admitting what you don't know, as well as not being able to reverse decisions in the face of refuting information, are the call signs of imminent project failure.

Projects that collapse fail to recognize that a plan is nothing more than a hypothesis, a (hopefully) educated guess about what is expected to occur over the future , if the assumptions at each point in time do not change.

Successful projects understand that decision uncertainty is not a risk, but a problem that must be worked everyday.

Counting the Cost of Bad Code

2011-12-09T21:11:00.000-08:00

A recent Wall Street Journal Tech Blog post takes a look at the hard costs of technical debt and shows that "I.T. Debt" is a growing concern:

It remains to be seen how efforts to affix a certain cost to technical debt can be used to provide a clear guide to business risks. But businesses are starting to pay more attention to the issue....technical debt [is] being raised as a due diligence issue in mergers and acquisitions, and increasing awareness of it is influencing software development practices.

Responsive Software Design

2011-12-03T10:26:00.000-08:00

In a Pragmatic Bookshelf article Kent Beck talks about Responsive Design and presents some interesting thoughts on software design.

Software design is difficult to master and it seems like we either fail to do it, or we over do it. The article does a good job of describing how to get the right mix of design:

Design is good. Design is central to effective software development. Programmers can add features steadily to well-designed software. Programmers can easily test well-designed software. Well-designed software is easy to tune for better performance. Most of the hard problems in programming turn out to be design problems.

But design has a dark side. While there isn’t a single best design for any system, there are many poor designs for that same system. The more experience a programmer has, the more design ideas he knows. The temptation is to put these design ideas in the system now because you just know you’ll need them eventually. Over-designing early leads to delaying feedback from real usage of the system, makes adding features more complicated, and makes adapting the design more difficult. By the same token, under-designing makes adding features more complicated, increases defects, and makes adapting the design more difficult.

The word “responsive” in the name of the project reflects this need for balance. Some design needs to be done in advance of coding, but over the life of the project most design will be done in response to the changing needs of the system and the changing and growing understanding of the developers.

Employee and Business Alignment

2011-11-29T22:02:00.000-08:00

In a recent Cutter Consortium post Vince Kellen explores what happens when employees are, and are not, aligned with their roles.

I've personally struggled with roles that weren't feeding my goals and passions. The post got me thinking about the larger picture where coworkers are struggling as well.

Some interesting points:

...I have seen all sorts of misalignments between bag A (personal skills, personal ambition and passion, level of effort) and bag B (current work role, future role I would like, my role in society and in this company overall). My sense is that these misalignments are endemic in all work places and are part of the human condition. I also know and have seen, however, that when a personally aligned team is aligned well in the organization, big things happen. These individuals and these teams tend to share a common attribute: a whole lot of heart. They are capable of giving more — much, much more.

When someone knows well what they are legitimately good at and what they can truly excel at, and when they are deeply passionate about all of this, watch out: anything can happen. These individuals work better and faster, produce better results, and, better still, because of their confidence, tend to work well with others. These people are often the glue that holds the place together. As others around them spin a bit out of control in misalignment or, worse, bust apart like a sliced golf ball, they tend to be a calming influence. These aligned people are intrinsically motivated and, like a gyroscope, stand on their own, more easily absorbing the slings and arrows of outrageous fortunes.

Hiring and Programming

2011-11-14T21:48:00.000-08:00

A post at developerart.com about hiring and programming had me engrossed. It's comprehensive and elicits both macro and micro thinking. I really liked this description of why we write software:

Besides, coding is not really the ultimate goal. We're not here to write the breathtaking code. We're not here to explore all of the hidden gems of some technology. We're not here to design a perfect bullet-proof architecture to accommodate for any future requirements in the next 50 (better 70) years. We've gathered together to develop software, to create a product, to solve specific problems and satisfy customers....One has to be able to simultaneously exist in several dimensions. In code when we're programming. In the needs and requirements we're programming for. In the mind of the users whose requirements we're putting in code. And also think of many other social, marketing and organizational aspects. Beyond code there are business processes, certain user experience. Don't forget usability. One has to see the big picture to excel. That special skill is however very difficult to check for when interviewing a candidate but it may happen to be even more important than coding skills or the advanced all-penetrating knowledge of the technology in use.

Quote of the Day

2011-11-10T21:15:00.000-08:00

Pay special attention to how a project begins because that's where the design tree is rooted. Right at the beginning is the easiest place to slip into major false assumptions, so learn to develop the habit to scrutinizing your starting point. - Donald C. Gause and Gerald M. Weinberg in Exploring Requirements: Quality Before Design

Don't Call Yourself A Programmer, And Other Career Advice

2011-11-07T21:53:00.000-08:00

Good software development career advice from Patrick McKenzie, who blogs about the business aspects of running a software company. Wish I had this 20 years ago!

Some points I like:

Most software is not sold in boxes, available on the Internet, or downloaded from the App Store. Most software is boring one-off applications in corporations, under-girding every imaginable facet of the global economy. It tracks expenses, it optimizes shipping costs, it assists the accounting department in preparing projections, it helps design new widgets, it prices insurance policies, it flags orders for manual review by the fraud department, etc etc. Software solves business problems...despite being soul-crushingly boring and of minimal technical complexity...it only matters that [the software] either saves the company costs or generates additional revenue.

Businesses do things for irrational and political reasons all the time, but in the main they converge on doing things which increase revenue or reduce costs.

The person who has decided to bring on one more engineer is not doing it because they love having a geek around the room, they are doing it because adding the geek allows them to complete a project (or projects) which will add revenue or decrease costs. Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.

...describe yourself by what you have accomplished for previously employers vis-a-vis increasing revenues or reducing costs. If you have not had the opportunity to do this yet, describe things which suggest you have the ability to increase revenue or reduce costs, or ideas to do so.

When Will the Project Be Done?

2011-11-03T21:59:00.000-07:00

Johanna Rothman provides an interesting perspective on estimating in But I Need to Know When the Project Will Be Done.

Like Johanna, I believe that time is better spent adding value, rather than producing estimates that are consistently wrong. The post leads off with a humerous and all-to-common conversation that highlights the problem with up front estimates:

Have you been able to [provide a perfect estimate] before?

No.

Do you think you can get a perfect estimate this time?

No.

Then why would you spend your time doing an estimate instead of producing something, learning from that and bettering your gross estimate?

Because my manager needs to know when the project will be done!

OO and Creating Changable Systems

2011-11-03T21:34:00.000-07:00

Inevitably, a valuable system is forced to change. The system is altered, again and again, to provide additional value. This altering takes the system in directions that were not envisioned when the system was created.

Given that OO development is well suited to dealing with the inevitable change, why are so many organizations not harnessing the power that OO provides for creating these changable systems?

Could it simply be ignorance? A lack of knowledge and training? Underestimation of the paradigm shift needed to truly understand and implement OO systems?

In future posts I'll elaborate on the tenets that make up the basis of my understanding of OO development:

Encapsulation
Low Coupling
High Cohesion
Separation of Concerns

The Soul of a New Machine

2011-11-02T20:46:00.000-07:00

If you're interested in what it takes to create technology, take a look at The Soul Of a New Machine by Tracy Kidder, a book that chronicles the trials and tribulations of creating the next generation computer. The author provides good rhythm and the right mix of human and technical factors. The suspense builds throughout the book and I was invested in the outcome: Will they finish? Will it be a success?

Even though the book was written in 1981, the rich descriptions of what goes on in a high-tech company are still accurate. Some common themes detailed in the book are time constraints, technical debt, complexity, chaos, attrition and turf wars.

I really liked the areas that focus on estimation and deadlines. Some passages that I recognized:

West and his staff had created the deadline of April and, in the act, had agreed at least to pretend to take it seriously. Many months later, Carl Carman would say that no one upstairs believed they would finish Eagle that soon. Some evenings downstairs, West seemed to say the same thing. "We're gonna finish this sucker by April, Alsing," he'd say. "Yeah, Tom. Sure we are," Alsing would reply. They'd smile at each other.

It's sort of a poker game. Everyone's bluffing, but everone seems to know the rules of the game...

"We went with an imperfect design," said Rasala. "We knew we were pushing it." So his schedules slipped and slipped, and slipped again. "the way to stay on schedule," he said, "is to make another one."

Logging Contrarian

2011-11-02T20:41:00.000-07:00

I'm a logging contrarian. Instead of each object declaring and using its own logger, I'd rather have objects that just expose formal notifications to the outside world. The objects shouldn't be concerned about how the notifications are presented or consumed. To me, this is just basic separation of concerns.

Steve Freeman has a couple of great posts (here and here) that provide collaborating information and ideas. I especially like his take on support vs. diagnostic logging and logging design:

The idea of encapsulating support reporting sounds like over-design, but it's worth thinking about for a moment. It means I'm writing code in terms of my intent (helping the support people) rather than the implementation (logging), so it's more expressive. All the support reporting is handled in a few known places, so it's easier to be consistent about how things are reported and to encourage reuse. It can also help me structure and control my reporting in terms of the application domain, rather than in terms of java packages. Finally, the act of writing a test for each report helps me avoid the "I don't know what to do with this exception, so I'll log it and carry on" syndrome, which leads to log-bloat and production failures because I haven't handled obscure error conditions.

IT Doesn't Matter

2011-10-26T15:26:00.000-07:00

I finally got around to reading Nicholas Carr's IT Doesn't Matter. It’s an interesting counter to the current, conventional thinking that Information Technology provides strategic value and can be used to gain a competitive edge:

Behind the [current] thinking lies a simple assumption: that as IT’s potency and ubiquity have increased, so too has its strategic value. It’s a reasonable assumption, even an intuitive one. But it’s mistaken. What makes a resource truly strategic – what gives it the capacity to be the basis for a sustained competitive advantage – is not ubiquity but scarcity. You only gain an edge over rivals by having or doing something that they can’t have or do. By now, the core functions of IT – data storage, data processing, and data transport – have become available and affordable to all. Their very power and presence have begun to transform them from potentially strategic resources into commodity factors of production. They are becoming costs of doing business that must be paid by all but provide distinction to none.

The piece is well reasoned and provides some compelling examples of other cases where ubiquity resulted in “commodity inputs” without strategic value.

So, what to do? Recognize and deal with the risks:

When a resource becomes essential to competition but inconsequential to strategy, the risks it creates become more important than the advantages it provides…. The operational risks associated with IT are many – technical glitches, obsolescence, service outages, unreliable vendors or partners, security breaches, even terrorism – and some have become magnified as companies have moved from tightly controlled, proprietary systems to open, shared ones. Today, an IT disruption can paralyze a company’s ability to make its products, deliver its services, and connect with its customers, not to mention foul its reputation. Yet few companies have done a thorough job of identifying and tempering their vulnerabilities. Worrying about what might go wrong may not be as glamorous a job as speculating about the future, but it is a more essential job right now.

Kanban vs. Scrum

2011-10-10T21:03:00.000-07:00

What is Kanban? How does it compare to Scrum?

Kanban and Scrum - making the most of both by Henrik Kniberg and Mattias Skarin is a mini-book that does a good job of explaining, comparing and contrasting Kanban and Scrum.

A New Approach for Mobile

2011-10-10T21:00:00.000-07:00

A recent Information Week article discusses the need for a mobile application strategy and lays out a concise plan of attack.

After starting with a logical premise - Mobile application development is a new animal, and IT leaders shouldn't expect to tame it using their same old tricks - the article presents the challenges and options for a mobile app environment.

While mobile has the normal life-cycle phases (development, distribution, security, support and enhancement) it's unique in that things are changing very rapidly and IT doesn't control the devices and platforms/operating systems.

Some important concerns about mobile devices:

Easily lost or stolen
Less reliable
Slower processors
Less memory
More expensive

The 8 major elements to consider in mobile strategy and some associated options:
1. Dev Environment

Customize per device, one app for multiple platforms or web-based app

2. Software Distribution

Over-the-air distribution, syncing with a PC or an "App Store"

3. Maintenance, Patches, Upgrades

Automatic user notifications, blacklist an earlier version and force upgrade

4. Security

Local storage, access, encryption, private networks, remote data clearing

5. User Support

Users' responsibilities and capabilities, training

6. Expense Management

Mobile networks vs. Wi-Fi

7. Support for New Platforms

Testing and certification, new mobile appliances

8. Your Mobile Policy

Governance

Working Effectively with Legacy Code

2011-10-07T14:23:00.000-07:00

A lucky developer is one who works on a new or green-field project. Unfortunately, maintaining/enhancing existing projects is the norm and in my new job I'm maintaining a couple of these existing "legacy code" projects. So now seemed like the right time to get to a book that has been on my list for a while: Working Effectively with Legacy Code by Michael Feathers.

Legacy Code has many definitions:

Code inherited from someone else
Code with a tangled, unintelligible structure
Code that's difficult-to-change
"Rotten" code

The author's definition is simple and somewhat unique: code without tests.

Code without tests is bad code. It doesn't matter how well written it is; it doesn't matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don't know if our code is getting better or worse.

To this I would add that legacy code is code that was written without any thought to how it will be tested.

In the forward, Robert Martin provides a nice summary of the book:

It's about taking a tangled, opaque, convoluted system and slowly, gradually, piece by piece, step by step, turning it into a simple, nicely structured, well-designed system. It's about reversing entropy

But, given the author's focus on tests, the book is all about how to change code so that it can be tested. The book is thought provoking and provides the techniques that can be used to "understand code, get it under test, refactor it, and add features."

A few points that resonated with me:

Preserving existing behavior is one of the largest challenges in software development. Even when we are changing primary features, we often have very large areas of behavior that we have to preserve.

Dependency is one of the most critical problems in software development. Much legacy code work involves breaking dependencies so that change can be easier.

What are the problems with big classes? The first is confusion. When you have 50 or 60 methods on a class, it's often hard to get a sense of what you have to change and whether it is going to affect anything else. In the worst cases, big classes have an incredible number of instance variables, and it is hard to know what the effects are of changing a variable. Another problem is task scheduling. When a class has 20 or so responsibilities, chances are, you'll have an incredible number of reasons to change it. In the same iteration, you might have several programmers who have to do different things to the class. If they are working concurrently, this can lead to some serious thrashing...

The later chapters are a bit hard to digest in isolation. I've found it best to keep the book handy as a reference when I encounter some legacy code that presents a specific problem.

Quote of the Day

2011-10-05T16:03:00.000-07:00

Launch simple, add complexity. - Jeff Barr, Amazon Web Services Evangelist, describing the AWS philosophy at a recent Technology Open House

What's Lean Thinking?

2011-09-30T15:07:00.000-07:00

So you've heard about Lean and Lean Thinking, "The Toyota Way" and kaizen and you're wondering what it's all about.

Craig Larman and Bas Vodde have created an excellent primer to get you on the path to understanding.

What Does Your Architecture Say?

2011-09-30T11:05:00.000-07:00

Once again, Uncle Bob nails it in Screaming Architecture.

Food for thought:

Architectures are not (or should not) be about frameworks. Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.

Your architectures should tell readers about the system, not about the frameworks you used in your system. If you are building a health-care system, then when new programmers look at the source repository, their first impression should be: “Oh, this is a heath-care system”. Those new programmers should be able to learn all the use cases of the system, and still not know how the system is delivered.

Quote of the Day

2011-09-29T21:42:00.000-07:00

...architecture is too important to be left exclusively to a few people. It's fine to have an architect, but the key way to keep an architecture intact is to make sure that everyone on the team knows what it is and has a stake in it. - Michael Feathers in Working Effectively with Legacy Code

Agile Exposes the Power Differential

2011-09-28T22:07:00.000-07:00

In a recent post Johanna Rothman talks about agile culture and focuses on one cultural aspect that I haven't though about: A power differential.

That’s the ability of the less powerful people in the situation to talk to the more powerful people in the situation.

Seems like the challenges constantly come back to communication. The take-away for me:

When I see organizations with a high power differential, they keep falling back to command-and-control approaches, because the power differential is so ingrained in their culture. This is why a transition to agile is not just a technical issue, but a cultural issue too.

The Code Doesn't Matter

2011-09-28T21:09:00.000-07:00

Saw an interesting artice today that presents Linus Torvalds' views on software development. One that resonates with me: the code doesn't matter.

The other thing ... that people seem to get wrong is to think that the code they write is what matters.

No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.

Way too many projects seem to think that the code is more important than the user, and they break things left and right, and they don't apologize for it, because they feel that they are ‘fixing’ the code and doing the right thing.

Quotes of the Day

2011-09-19T21:40:00.000-07:00

"...the complexity of the problems you're able to solve is directly related to the the kind and quality of abstraction"

"Programming is about managing complexity: the complexity of the problem you want to solve, laid upon the complexity of the machine in which it is solved" - Bruce Eckel in Thinking In Java

You're Agile? Really?

2011-09-16T10:51:00.000-07:00

Agile Software Development recently celebrated its 10-year anniversary and many claim to be Agile. But, what is it?

Agile Software Development is a set of generative approaches that aim to reduce the cost of the inevitable change that occurs throughout a project.

Agile means:

short iterative cycles
feature-based planning
constant feedback
change tolerance
team proximity
customer intimacy
a focus on the overall team ecology

Early on two of the originators of Agile - Jim Highsmith and Alistair Cockburn - created an excellent and comprehensive description. It contains two parts:

Let the Store Come to the People

2011-09-16T09:42:00.000-07:00

In a previous post I wrote about harnessing the power of technology to improve lives and increase effectiveness.

Two common themes for harnessing technology are:

Automating mundane tasks so there's more time to deal with complicated ones.

Surfacing problems early so there's more time to deal with them.

A good example of the first is shopping while waiting for a train.

Where Are Windows Files in Ubuntu?

2011-08-27T08:40:00.000-07:00

I'm running a dual boot of Windows 7 and Ubuntu 11.04 on my laptop and I didn't know how to access a couple of files that I created in Windows.

I searched the web - "where are windows files in ubuntu 11" - and got a bunch of hits related to creating directories and mounting NTFS drives.

I kept thinking that there has to be a better way. And there is: the windows partition is automatically mounted as "file system / host".

Lyrics of the Day

2011-08-25T21:38:00.000-07:00

I spoke to a man down at the tracks.
I asked him how he don't go mad.
He said "Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad."
Television - Marquee Moon

Quote of the Day

2011-08-25T21:37:00.000-07:00

“…vast software riches await in waters that have been chartered extensively but are traveled infrequently by average software practitioners.” – Steve McConnell in Professional Software Development

Driving Technical Change

2011-08-14T11:44:00.000-07:00

In a past job I was constantly advocating for better OO practices and tools. I found myself having to repeatedly explain and discuss the well documented benefits of OO and Agile methodologies. This apathy towards technical excellence is the main reason I left this job.

I didn't really think about driving change as a formal process so I was interested to read Driving Technical Change by Terrence Ryan. I really liked the book's basic premise that exactly matches my experience: Driving technical change is simple, but not easy.

The author does a great job of describing the roles, participants and process, and the reasons people resist and push back against change. In addition, the author emphasizes that any change should be the right change - both necessary and beneficial.

It's a lot to take in but I'll definitely keep the book handy as another reference to aid software development.

End of Another Chapter

2011-08-11T21:55:00.000-07:00

A couple of years ago I made a conscious decision to take charge of my career and not settle for a job that wasn't in line with my goals.

So, in keeping with that decision, I've started a new job this week where I'll actually be writing code again.

I'm looking forward to the challenge and the opportunities to come.

Are Software Failures Inevitable?

2011-08-04T21:56:00.000-07:00

A recent On Quality Blog post asks a provocative question: When exactly did we decide that software failure was an unavoidable part of business?

The post looks at the recent series of computer systems outages among U.S. air carriers and notes that acceptance is an inevitable result:

Truth is, software failures like the ones experienced by the airlines have become all too commonplace in all industries. We treat news of software failures as though they were inevitable and almost expected and, particularly with an industry like the airlines, we accept the apologies that are granted because we have no other alternative than to do so.

As to why, the post notes a common basis:

… many of the problems stem from existing software that has either been upgraded, customized or had new versions built on top of it.

The post focuses on the need for structural quality of software and lists some compelling reasons for poor quality:

Most developers are not experts in their particular domain initially and most of the learning comes only by correcting mistakes.

Applications are a complex array of platforms, business logic and data management that interact through middleware with enterprise and legacy systems. Since developers cannot know everything they make incorrect assumptions and decisions.

The break-neck speeds at which developers are asked to ply their craft often means software quality becomes a sacrificial lamb.

When new software is built on existing code developers must spend much of their time trying to figure out what the "old code" did. If time or complexity constraints prevent a full understanding, then "work arounds" are introduced.

Poor quality may be introduced via mergers and/or acquisitions.

What's Your Smartphone Strategy?

2011-08-01T15:41:00.000-07:00

According to Nielsen, smartphones are now the majority of new cellphone purchases in the U.S. and it is estimated that by year end there will be more smartphones in the market than feature phones.

You have a smartphone strategy, right?

Omnipotent Hackers - A Second Threat

2011-08-01T15:03:00.000-07:00

In a recent Information Week article - Omnipotent Hacker Myth Lets Business Off The Hook - Andrew Conry-Murray explores the ramifications of hackers' growing aura of invincibility.

More and more, hackers are seen as uncontrollable:

News coverage has portrayed hacker groups ... as capable of striking down mighty (though mortal) targets at a whim, including law enforcement, three-letter government agencies and major corporations.

The result:

...if the hackers are portrayed as omnipotent, companies will take even less responsibility for protecting ... information

...if the public sees intrusions as unstoppable acts, how can it blame the victim?

...Companies have always weighed the costs of security against those of a potential breach, but in an era of omnipotent hackers, the balance shifts. The thinking becomes: Do I want to A) spend lots of money on security with no guarantee of protection, or B) put that money elsewhere and risk an intrusion? If you know an intrusion isn't going to cost you customers, option B becomes more palatable.

Solving Problems vs. Creating Solutions

2011-07-27T22:02:00.000-07:00

A common problem with software development is that the solutions we create often don't really fit the targeted problem.

In a posting about domain language - Whose domain is it anyway? -, Dan North provides a couple of "story" examples that illustrate how a simple change in thinking can ensure that a solution fits a problem.

Example 1 - a solution-based approach:

Given an unauthenticated user
When the user tries to navigate to the welcome page
Then they should be redirected to the login page
When the user enters a valid name in the Name field
And the user enters the corresponding password in the Password field
And the user presses the login button
Then they should be directed to the welcome page

Example 2 - a problem-based approach:

Given an unauthenticated user
When the user tries to access a restricted asset
Then they should be directed to a login page
When the user submits valid credentials
Then they should be redirected back to the restricted content

In the first example, the focus - pages, fields, buttons - is narrow and all about the implementation of a solution.

The second example is more abstract and is focused on the problem to be solved. The benefit here is that this problem will stand on its own regardless of how it is implemented, which can change over time.

Smarter Products

2011-07-27T22:00:00.000-07:00

I read an IBM/Rational Software white paper today - Turning product development into competitive advantage. Best practices for developing smarter products - that really focused my thoughts about the future of technology and the new and exciting ways we can take advantage of technology.

I work in Information Technology because I'm passionate about harnessing the power of technology to improve our lives and make us more effective. The paper's definition of "smarter products" is all about harnessing that power:

As you exit your driveway, your car sends a signal to your home to arm the alarm system while your cell phone automatically synchronizes with your car’s voice command system. Having analyzed your recent driving patterns, the vehicle’s global positioning system (GPS) recommends a new route to cut fuel costs and avoid traffic delays. Finally, the car informs you that your antilock brakes need servicing and, after checking the schedule on your personal digital assistant (PDA), presents you with available appointment times.

Software Spectrum

2011-07-26T20:54:00.001-07:00

Software development has a spectrum. At one end is the business domain or the context for the problem to be solved. At the other end is the technology - the code, tools and systems that solve the problem.

There are many roles spread across this spectrum. Some common ones are User, Domain Expert, Business Analyst, Project Manager, Technical Analyst and Developer.

Where do these roles fit on the spectrum? Is there a standard for where they fit?

User and Developer are easy - they are at the ends. Project Manager is somewhere in the middle. Domain Expert and Business Analyst are somewhere between the middle and the business domain. Technical Analyst is somewhere between the middle and the technology.

As a software developer, what roles do you interface with? What roles influence you? What roles provide the knowledge you need in order to do your job?

If the majority of your interface is on the right side of this spectrum then your knowledge and experience is second-hand and chances are you aren't even aware of the problem. As a result, you are probably creating software that doesn't reflect the business domain. And unfortunately, the result is that the problem domain is often altered to fit the solution.

Uber Conference 2011

2011-07-15T18:11:00.000-07:00

I attended the 2011 Uber Conference in Denver this week and while it didn't "blow my mind", it did provide for some great camaraderie, learning and discoveries. The space, amenities, food and sessions were great. The only complaint I had is with the wireless access, which was spotty and very sloooooow.

The conference bills itself as "ultimate Java platform/agility experience" and it definitely delivered on the Java platform part. The most interesting sessions for me, and the ones that made the most impact, were the ones related to jRuby and the Spock testing framework. I still can't believe how easy mocking is with Spock.

I had some great conversations and I picked up a few shortcuts and recommendations for personal productivity applications. For example, I downloaded Evernote to capture my conference notes.

As in the last conference I attended, I was awed by the way new frameworks are abstracting away the tedious and repetitive parts of software development that don't add value.

I've got a long list of tools and technologies to explore and I need to understand closures and mixins.

On day one I attended the full day Android Workshop by Ted Neward where I got some exposure to Android, which appears to be a blend of Java, open source, and a mobile device platform. I developed the sessions's simple app using the SDK, development environment and emulator. The Android API is a different mental model for me. Another paradigm shift. It seems a lot like the Java Swing event model with registration and call backs.

At the end of the day my mind was full of Android but it was a lot of fun to expand my knowledge and stretch my Java comfort zone.

In the day 1 keynote presentation Terry Ryan talked about how to overcome the common resistance you'll encounter when you try to implement the technologies and tools you're passionate about. Terry spoke about the patterns, and personas that you'll deal with. As Terry pointed out, overcoming the resistence is simple, but not easy.

Day 2 was the official start of the conference. I attended the following sessions:

Continuous Delivery I and II by Jez Humble

Continuous delivery aims to avoid long periods between an idea that may provide value and the ability to determine if the value is real. The goal is to release minimum marketable features quickly and get immediate feedback. Also, continuous delivery results in software that's always ready so that software is not a company's bottleneck.

Jez posed a great question worth pondering: How long would it take your organization to deploy a change that involves just one single line of code?

Using DDD Patterns for Supple Design by Paul Rayner

This session was right up my alley because it dealt with ideas I've been exploring in my blog. I really enjoyed the discussion about ubiquitous language since I've been advocating for it at my current job. Some of the Domain Driven Development patterns that were presented: Entity, Value Object, Event, and Service.

Designing RESTful Services by Ian Robison

I'm currently reading Ian's book REST In Practice and struggling to comprehend the concept so it was good to get some additional perspectives. This was the most popular session that I attended.

My take is that REST is about avoiding coupling in machine to machine interactions by simply using the standard HTTP interface. The goal is to execute a specialized processes in a generalized way by focusing on what to do next and/or how to progress. A key point is that the "application" is what the client perceives it to be - the server is just a collection of resources that "look out for themselves" and aren't concerned about the overall goal the client is trying to accomplish.

Effective Java Reloaded by Matt Stine

This session was about writing better Java code by applying the tenets in the book Effective Java. The following tenets were review/discussed:

Make defensive copies when needed
Obey the general contract when overriding equals
Always override toString
Consistently use the Override annotation
Prefer primitive types to boxed Primitive
Use overloading judiciously
Remove empty arrays or collections, not nulls
Minimize scope of local variables

Java Web App Security: Develop. Penetrate. Protect. Relax. by Matt Raible

This session demonstrated how to implement web authentication via Java EE Servlet 3.0, Spring Security and Apache Shiro.

Software Craftsmanship: Positioning, Patterns and Practices by Peter Bell

This session, the sixth of the day, was a good day ending one since it mostly high-level and based on familiar concepts. We took a look at the state of the Software Craftsmanship movement and discussed its history, philosophy and practices.

There was an interesting discussion about the dust-up earlier in the year regarding the value of Software Craftsmanship.

On Day 3 I attended the following sessions:

JRuby in Depth I and II by Neal Ford

This was one of the two sessions that really made an impact. I hadn't previously thought about taking advantage of Ruby with existing Java projects. JRuby makes it possible. Ruby is just one of over 200 languages that run on the JVM but it's one of the oldest and most mature/stable.

This session presented a demo of jRuby and the Ruby syntax.

Git Workshop by Matt McCullough

I've been using Git and github as my code repository so this session didn't present anything significantly new but I did pick up a few shortcuts and ideas.

Tricks of the Trade - What Every Developer Should Know About App Security by Frank Kim

This session was a real eye-opener. Frank showed just how easy it can be to exploit app security flaws. He demo'ed how to exploit flaws with Cross-Site Scripting, Cross-Site Request Forgery and SQL Injection.

A couple of take-aways: hacking is not hard, and don't trust any data coming into your app - either from the client or your own persistence.

Design Patterns in Modern JVM Languages by Venkat Subramaniam

In this session Venkat demonstrated how the newer JVM languages (Scala and Groovy) make it easier to implement the following patterns:

abstract factory
cascade
fluency (closures)
pluggable behavior
decorator
execute around method
intercept, cache, invoke
delegation

On the final day of the conference I attended the following sessions:

Smarter Testing With Spock by Peter Niederwieser

Peter is author of Spock and provided some of the motivations and use-cases that were used to create Spock, which is a Developer testing framework based on Groovy, written in Java, and compatible with JUnit.

Peter presented demo's of the major facets of the framework. I was amazed and the simplicity and the obvious, self explanatory syntax of Spock. I was really floored by the ease of mocking and stubbing.

I'm looking forward to actually using this framework.

Functional Web Testing With Geb and Spock by Peter Niederwieser

I was a little lost in this presentation because I've not done web page testing and I'm not well versed with jQuery. But Geb is a powerful tools that really works for web testing.

All-in-all it was an excellent 4 days. Very enlightening and energizing.

Leader-Full

2011-06-28T17:25:00.000-07:00

I attended the recent Beyond Agile gathering where Esther Derby talked about different types of leadership and the benefits of "Leader-Full Teams". One of her main points was that the classic model of leadership - a single, charismatic figure and the followers - is outdated and doesn't fit today's software development world with its agile knowledge workers. Instead, we form "goal oriented social units" where each member is a leader and is empowered to make small, subtle decisions and changes that ripple out with positive effect.

For example, instead of a leader directing the team to "be more creative", a team member can throw out a wild idea to promote challenges and counter ideas.

A leader...

is self-aware - blind spots, filters, strengths/weaknesses - and aware of group and system dynamics.

has tools and options for action, knows the relationships between them, and combines them to achieve desired outcomes.

combines differences - skills, ideas, thinking - for effectiveness.

tightens constraints to focus a group's attention or applies them to add organization to chaos.

As a bit of an experiment, Esther got the group to form small teams tasked with creating an objet d'art. The only requirements were height, strength and beauty, which led to some amazing creations and the highlighting of a valuable tool/option: don't over specify.

The Psychology of Computer Programming

2011-06-11T22:58:00.000-07:00

How do we make programming and software projects better? More successful? One way may be to pay more attention to the human, or psychological side. In my experience, we rarely look at psychological issues related to software development.

Prior to reading The Psychology of Computer Programming by Gerald Weinberg I only thought about a small part of the human side of software development. The book deals with subjects that are rarely discussed or addressed:

Personality traits
Leaders and leadership
Physical environments
Social organization and common social problems
How a team forms
Formal and informal structures at work in teams
Motivation
Training
Forces against learning

As usual, Gerald Weinberg tells some great stories although this book was a little hard to get through since it read mostly like a text book. It was a bit dated but it contained some great anecdotes and timeless themes.

The book's main point is thinking about computer programming as a human activity and programmers as a human beings, rather than machines. The benefit would be programmers functioning more efficiently and with greater satisfaction.

The book discusses why the human side is overlooked:

Computer programming is a human activity. One could hardly dispute this assertion, and yet, perhaps because of the emphasis placed on the machine aspects of programming, many people - many programmers - have never considered programming in this light. Among programmers, there is a certain mystique - a certain waiving of the hands which takes place whenever one tries to probe the manner in which programming is done. Programming is not done in a certain way, they say, it is just done. Either you can program or cannot. Some have it; some don't.

Some food for thought:

Writing a program is a process of learning - both for the programmer and the person who commissions the program. Moreover, this learning takes place in the context of a particular machine, a particular programming language, a particular programmer or programming team in a particular working environment, and a particular set of historical events that determine not just the form of the code but also what the code does!

In a way, the most important reason for studying the process by which programs are written by people is not to make the programs more efficient, more compact, cheaper, or more easily understood. Instead, the most important gain is the prospect of getting from our programs what we really want - rather than just whatever we can manage to produce in our fumbling, bumbling way.

There are many reasons why programs are built the way they are, although we may fail to recognize the multiplicity of reasons because we usually look at code from the outside rather than by reading it. When we do read code, we find that some of it gets written because of machine limitations, some because of historical accidents, and some because of specifications - both essential an inessential. But for whatever reason a particular piece of code gets inserted into the final product, there are psychological aspects to that reason.

Putting a bunch of people to work on the same problem doesn't make them a team.

Each person working on a team within a project has come to accept certain of the team goals as his own. But when the team is specialized, its goals do not necessarily coincide with the overall goals of the project, or with the goals of another team. These conflicts are invariably manifest is some sort of social relations.

The job of getting from specifications to delivered program demands various kinds of work, which in turn, demand various talents...it may be that suitability for work in one stage of programming makes one more or less unsuited for work in another.

Personality affects programming performance.

If we are to ensure that the proper talents are available when needed, we shall have to classify the work that programmers do into somewhat more refined categories than the simple term "programming" covers.

An interesting topic was egoless programming or the ability to realize human limitations and the restructuring of the values system of programmers. Programmers should look for and welcome criticism, and realize that we all have bad days or days where we are just not going to produce anything of value.

I really liked the section that discussed documentation:

The value of documentation is only to be realized if the documentation is well done. If it is poorly done, it will be worse than no documentation at all.

There is no way to force programmers to produce good documentation...The only hope for producing good documentation is to convince the programmer that is will benefit him to do so. If the act of producing the document has demonstrable good effects, there will be no way of preventing reasonably good documentation.

"Depth" is one of the most important documentation concepts, especially for large systems. If a system is of any size at all, different users of the documentation will need different levels of detail in the information they extract. The highest level should be just sufficiently detailed to tell the user whether or not he will be able to read the documents. At each level - because we can never be sure which document will fall into the user's hands - the first and most conspicuous thing in the document should be a reference to the documents above and below it in depth, along with an indication of the the depth to which the document goes and the knowledge the reader must have to use it.

We have not accustomed ourselves to thinking of the cost of documentation as a part of the programming cost.

There is no reason to believe that a professional programmer will be qualified as a professional documenter.

This book makes the case that software development is not always just hardware and software. We humans are the main part of the equation and therefore software development carries all the issues and challenges as any other human endeavor.

I really liked the book's description of the greatest challenge as "not creative thinking, but creative communicating: representing our thoughts in a way that other persons - each with a unique style - can understand."

Is Experience Valuable?

2011-06-10T13:37:00.000-07:00

I viewed a couple of the presentations from the Agile Connect 2011 event this week. One of my interests is software estimation and the challenge of estimating accurately so I really enjoyed the Deception and Estimation: How We Fool Ourselves presentation.

A couple of key points:

We deceive ourselves in all our daily estimates and we're hardwired to deceive

Deception is rampant in our daily lives and even encouraged For example, we instruct our children to feign respect for their elders, to write thank you notes for disappointing presents and to refrain from telling grandma that her breath stinks

What was most interesting to me was the article that was referenced in the presentation - The Experience Trap - where the main element of estimating, experience, was shown to be ineffective when dealing with complexity.

A key paragraph from the article:

When anyone makes a decision, he or she draws on a pre-existing stock of knowledge called a mental model. It consists largely of assumptions about cause-and-effect relationships in the environment. As people observe what happens as a result of their decisions, they learn new facts and make new discoveries about environmental relationships. Discoveries that people feel can be generalized to other situations are fed back, or “appropriated”, into their mental models. On the face of it, the process seems quite scientific — people form a hypothesis about a relationship between a cause and an effect, act accordingly, and then interpret the results from their actions to confirm or revise the hypothesis. The problem is that the approach seems to be effective only in relatively simple environments, where cause-and-effect relationships are straightforward and easily discovered. In more complex environments, such as software projects, the learning cycle frequently breaks down.

So, cause-and-effect and mental models don't work well in complicated environments like software projects but, because humans are not good at dealing with complexity, we tend to use software to help with complex situations.

I've often wondered about how software project failures would be different if we spent less time on estimating and more time on actual problem solving.

Quote of the Day

2011-06-05T00:00:00.000-07:00

Documentation is the castor oil of programming - managers think it is good for programmers, and programmers hate it! - Gerald Weinberg in The Psychology of Computer Programing

Understand the Problem

2011-05-21T22:08:00.000-07:00

I came across an interesting post with an anti-pattern that dovetails nicely with my focus on solving problems:

Understand the Problem vs. Jump to the Solution – only a couple of minutes into our discussion solutions were being flung about like drunken darts. This situation almost always leads to suboptimal or faulty solutions. As a facilitator, try to ensure that the problem has been clearly stated. If at all possible, write it down on a whiteboard. Make sure everyone agrees that the problem as stated is the problem the group is there to solve. Sure enough, after performing this exercise, we all had a very different and clear understanding of the problem than that with which we walked in the door.

Q & A

2011-04-24T20:57:00.001-07:00

“What if we train our people and they leave?”
“What if we don’t train our people, and they stay?”

Pragmatic Thinking and Learning

2011-04-23T09:01:00.000-07:00

The problem with common sense is that it’s not that common. I was reminded of this old adage while reading Pragmatic Thinking and Learning because the book is full of common sense things that I've forgotten.

For example, I need to use mind mapping as a note taking tool because it makes follow-up and retention so much easier. Also I need to resume my meditating - my sleep is so much better when I do.

The book explores the non-technical side of software development. A few areas I especially liked:

The use of symbols to aid learning. I can now remember left brain (analytical/empirical) vs. right brain (creative) based on the "R" and "L" symbols.

The explanation of the Dreyfus Model of Skill Acquisition. It made me think about where I am in my career development.

The discussion about context switching and the design/use of multiple monitors.

Learning about infinite regression.

Some takeaways for me:

Don't try to herd racehorses and don't try to race sheep.

In systems thinking as in object-orient programming, it's often the relationships between things that are interesting , not the things themselves.

There's always going to be a new technology to be learned. The technology itself isn't as important: it's the constant learning that counts.

When transitioning from one skill to another, you need to unlearn just as much as you need to learn.

Hello Mac!

2011-04-17T08:09:00.000-07:00

I got my first Mac (MacBook Pro). I unpacked it on Friday evening and as of now (Sunday morning) it's completely replaced my Win 7 laptop. I've installed all my social stuff and my dev tools, and I've pulled in all my code from github.

Operating the new hardware/software involves a bit of a paradigm shift but I'm enjoying the challenge of learning. After using the terminal utility to get my git environment set up I realized how much I miss the bash interface and vi!

A few things led me to the switch:

My laptop was regularly giving me the BSOD and I was constantly saving my work as a preventive measure.

My battery life was only in the 1.5 to 2 hour range.

The laptop power connector was constantly being pulled out or in the way.

The Mac's compact size and its reputation. Almost all of the seminars, training classes and webinars I've been to/seen are presented on Macs.

Solving Problems (with software)

2011-03-31T12:39:00.000-07:00

IT project failures are all too common and in my 25+ years of software development I've seen my share. I've personally been involved in projects that were:

Never completed
Never implemented
Without value and/or loaded with additional work for the user

These failed projects all suffered from the same common problem: poor requirements. Those involved were either unable or unwilling to define and communicate not only what was being created, but, just as important, why it was being created. There was no notion of the project's value.

This requirements problem is certainly well know and discussed. Fred Brooks summed it up nicely in his popular essay No Silver Bullet - Essence and Accident in Software Engineering:

...the hard part of building software is the specification, design and testing of the conceptual construct (data sets, relationships, algorithms), not the labor of representing the construct and testing the fidelity of the representation.

Without well defined and communicated requirements we get poorly-implemented, over-engineered solutions to misunderstood problems. And, we get the following types of conversations:

User:	How do I save the order?
Developer:	You can't save the order, you haven't entered the due date.
User:	The due date isn't supplied at the time of order entry ...

User:	How do I get to client ABC?
Developer:	Use the client drop down.
User:	But it's sorted by client number.
Developer:	So?
User:	I never access clients by their number ...

Project Manager:	How do you like the new inventory system?
User:	It's great but I can't find the low stock report.
Project Manager:	That wasn't in scope ...

Why is it so hard to capture and communicate requirements? In a word, complexity. Software is increasingly complex and, since we tend to tackle the "easy" problems first, each new problem is more complex.

I've always been humbled and mindful of my project failures, and I've spent many hours contemplating better ways of defining requirements that would lead to more successes. I've been heavily influenced by Gerald Weinberg, Martin Fowler, Tom DeMarco, Timothy Lister and James Shore.

Communication is the key, of course. But in coming up with what to communicate we must remember that software is a means to an end. We must postpone the creation of the solution until we understand the problem, and we must focus on problem solving, not writing software.

Also, communication cannot be one-dimensional and one-way. You need feedback, because everyone has different knowledge, experience and assumptions, and you need non-verbal themes to guide and facilitate. I've identified five key themes that have been prominent in my successful projects:

Ubiquitous Language
Communicating clearly and accurately, especially regarding complexity, is made difficult because human language is so imprecise. Multiple terms or words can mean the same thing and a single word or term can be understood to mean different things. Now mix in team members at different levels of experience, understanding, skills and responsibilities, and confusion and errors result. A Ubiquitous Language can help deal with this.

Ubiquitous Language (UL) is a simple concept: All members of the team use a common language - the same language - to understand and describe, and it's the language of the problem domain. The UL is used verbally, in written documentation and most importantly, in the code.

Without a UL, precious time is wasted with misunderstandings and translations. With a UL, ambiguity is reduced and communication is clear and accurate. Another important benefit is that all the team activities are connected with the code.

James Shore has talked about UL as a key part of Agile Development. In addition, UL is a key concept in Domain-Driven Design.

Ground Truth
Ever been to a planning/estimating meeting where developers roll their eyes when a go-live date is announced? Ever been to a release demo where user's are focused on what's missing instead of what's presented? These are examples of what happens without ground truth, or shared assumptions and facts that are aligned with reality.

In software we use models - schedules, documents, pictures - to aid decision making regarding scope, dates, quality and risks. But the models are only valuable when they're rooted in reality. And that means they must be constantly reviewed, evaluated and adjusted to reflect the truth.

With ground truth the commitment and involvement of all team members is enhanced because everyone believes in the assumptions and facts used to make decisions.

Solution Abstraction
When first contemplating how a software project will be done it's important to pull back from the mechanics of UI's, frameworks and protocols and think of the project as a value abstraction, focusing on the problem and pain points that are to be addressed/eliminated. I've found it helpful to explore how the problem could be solved without a computer. Client drop-downs and order entry screens are future details to be address after you discover and define the real value is notifying a client when their order cannot be fulfilled.

Constant Context
One of the first books I read when I was transitioning to OO was UML Distilled by Martin Fowler. The first few chapters did a good job of introducing this newbie to OO software development. One of the concepts that made a lasting impression was the use of Perspectives. Fowler described three perspective used with class diagrams:

Conceptual - the concepts in the domain
Specification - the interfaces
Implementation - how the classes are implemented

These perspectives are also commonly used in all forms of communication related to requirements. I've found it helpful to stay away from Implementation perspective so that your focus is on the solution, not the software. Conceptual and specification perspectives are better suited for requirements but a constant context - the consistent use of one or the other - is necessary so that you can focus on the requirements without having to mentally shift between levels. Its much easier to stay at a conceptual level, for instance, than to have to think conceptually and then shift into details and then back to concepts.

Bridge, Not Ferry
One of the parts of Agile development that I really like is the goal of bringing teams together so that collaboration and Q&A are immediate and so that team members are exposed to day-to-day project details. This team togetherness is only possible if the "gap" between the different groups on the team is not an impediment. Historically, there's been a disconnect between business people and developers - described well as a yawning crevasse of doom. You need a bridge to provide direct communication between team members. You don't want team members ferrying information and decisions back and forth across the divide.

Quote of the Day

2011-03-30T20:33:00.000-07:00

A company is more likely to die of indigestion from too much opportunity than starvation from too little - David Packard, co founder of HP

QA vs. QC

2011-03-30T20:23:00.000-07:00

In an earlier post I took a look at Quality Assurance vs. Quality Control. I find that there's an almost universal mislabeling of testing groups as QA when they're really QC.

This week I attending a webinar where Capers Jones discussed software quality. In the Q&A session I asked Capers if he makes a distinction between QA and QC and his answer was consistent with my thinking:

Quality Assurance - concerned with ensuring, measuring and increasing quality
Quality Control - concerned with problem detection and removal

DRY SOCs

2011-03-23T15:20:00.000-07:00

I'm taking a Core Spring training course this week and I'm really enjoying the challenge of taking it all in. Core Spring is extremely powerful and comprehensive. It really eases the burden of developing enterprise applications.

At the start the trainer presented the overriding tenet for Spring as an acronym: "DRY SOCs". That is, Don't Repeat Yourself and Separation of Concerns.

That got me thinking about the acronyms/tenets that I've embraced. Here are a few:

DTI - Design To Interfaces

LCSC - Loose Coupling / Strong Cohesion

FCOI - Favor Composition Over Inheritance

SUFC - Separate Use From Construction

TWVAEI - Take What Varies And Encapsulate It

DOD - Do Or Delegate - A class/method should either do work or delegate work to others. When it does both it's less cohesive and harder to understand and test. Also know as the Sargent/Private principle: either give orders or take orders.

LYTOP - Limit Yourself To One Perspective - A class/method should operate at either the conceptual or implementation level. Comprehension is easier when you don't have to move between the perspectives.

And, of course, the revered acronym of acronyms: SOLID

QA Isn't

2011-03-20T09:03:00.000-07:00

The Quality Assurance team. Every software project needs one. Software bugs are a fact of life and QA teams are skilled at discovering and eliminating them.

But this isn't quality assurance really. An emphasis on uncovering defects is more like quality control.

In true QA, the quality is built-in and the entire team is focused on quality at every phase of a project.

A recent post in the On Quality blog revived my concern about the almost universal lack of true quality assurance. I often wonder if quality would increase with a focus on the distinction between Quality Control and Quality Assurance.

On Quality's post gets strait to the point:

Does software quality come from testing?…No.

The problem is that QA's concern with what's seen doesn't address the unseen. And that, like an iceberg, is the larger part:

Testing can only address an application’s “external quality.” Testers can effectively address only visible symptoms such as correctness, efficiency or maintenance costs. What lies beneath the surface, however, the internal quality, directly impacts the external quality and can lead to even greater issues. These characteristics – program structure, complexity, coding practices, coupling, testability, reusability, maintainability, readability and flexibility – are the invisible root of the software quality iceberg and can do far more damage to a company’s reputation and IT maintenance budget than the visible issues.

The traditional approach, where quality is left to the developers, is problematic for a couple of reasons:

...time, business and cost pressures have all pushed developers to make sub-optimal choices that impact the quality and future performance of critical applications.
...there is just too much that needs to be reviewed for any individual developer – or even group of developers – to review efficiently and find the issues that could lead to application software malfunction.

The post recommends using automated tools to accomplish successful internal quality reviews. But before that happens, I'd advocate for a development process that spends more time on ensuring quality is built-in rather than ensuring that bugs are taken out.

Persistence Ignorance

2011-03-17T19:42:00.000-07:00

Came across a great term today that well defines the goal of keeping the domain free of anything related to how data is persisted: Persistence Ignorance.

Quote of the Day

2011-02-26T08:25:00.000-08:00

...the problem with being clever and original in software design is that it gets to be a habit - you start reflexively making things cute and complicated when you should be keeping them robust and simple. - Eric S. Raymond in The Cathedral and the Bazaar

Ruby Primer

2011-02-22T21:13:00.000-08:00

I had a bit of good luck this week. I found and attended a free Ruby Primer course given by Jeff Casimir of jumpstartlab. I've dabbled a bit in Ruby and the primer provided a wealth of new learning.

The course was excellent, both in content and presentation. Jeff's background in education and teaching gives him a unique style - he's engaging and knowledgeable. If you're in to Ruby/Rails, take a look at jumpstartlab's offerings.

Quote of the Day

2011-02-22T21:12:00.000-08:00

I'm one epiphany short of a paradigm shift. - Unknown

Goals 2011

2011-02-20T10:49:00.000-08:00

Well, it's the middle of February and I'm just now getting to my goals for 2011. Better late than never!

2010 was significant for me because I took charge of advancing and promoting my career. The most important event was my job change which provided much needed momentum and new challenges and learning.

For 2011 I want to continue the learning that I've started. I want to focus on 2 things:

My thinking, to get some maturity on the human and sociological thoughts and concepts that I've been gravitating towards -
How to be effective and not just efficient
How to add value and solve problems, with or without software
How to foster an environment that promotes the above

My technical skills in common enterprise frameworks such as Spring, Hibernate and Groovy/Grails

So, in 2011 I will ...

1. Read 5 software development related books
There are currently 10 books in my "to read" stack and if history is a guide, that stack will grow. This goal is a little less ambitious than last year due to goals 2 and 3.

2. Convert my "broken toy" library app to use Hibernate and Spring
I want to expand my knowledge and skill with these frameworks and I need to do it on my own since I'm not working with them in my job.

3. Create a new "broken toy" app to help me keep track of the anniversaries and birthdays of my family and friends
I'm always forgetting them so I could use some help.

4. Write two blog posts a month
Continue with what I accomplished last year.

5. Take some sort of multi-day software development training
This will be a reoccurring goal.

The Design of Everyday Things

2011-02-14T22:16:00.000-08:00

When I started reading The Design of Everyday Things by Donald A. Norman I recalled when I encountered my first "Norman Door." It had the same handles on both sides but only opened one way. I scratched my head and pondered how best to operate the door. And then felt really dumb when I chose the wrong way.

According to the author,

Far too many items in the world are designed, constructed and foisted upon us with no understanding - or even care - for how we will use them. Calling something a "Norman door" is recognition of the lack of attention paid by the maker to the user

I've been involved in numerous software projects that suffered from Norman doors, so I read this book to get a general understanding of what is a good design. The book delivered, highlighting both good and bad designs. And, now I no longer feel dumb when I fail at using a bad design.

The book aims to answer a couple of questions:

When we first see an object we have never seen before how do we know how to use it?

How do we manage tens of thousands of objects, many of which we encounter only once?

Good designs provide:

Feedback so you know when something has or is happening
Constraints so it is impossible or not easy to make errors or mistakes
Affordances that show appropriate actions and hide inappropriate ones
Conceptual Models providing clues to how something works
Natural Mappings that take advantage of physical analogies and cultural standards

I really enjoyed the chapter titled "Knowledge in the Head and in the World". Some important points for me:

In everyday situations, behavior is determined by the combination of internal knowledge and external information and constraints.

Whenever information needed to do a task is readily available in the world, the need for us to learn it diminishes

There are two types of knowledge: Knowledge of (facts, rules) and knowledge how, which is difficult to teach

Memory storage and retrieval are easier when the material makes sense and it fits into what is already known

The difficulty of dealing with novel situations is directly related to the number of possibilities

A couple of points that are especially applicable to software development:

Creeping featurism is a disease, fatal if not treated promptly. There are some cures, but, as usual,the best approach is to practice preventive medicine. The problem is that the disease comes so naturally, so innocently. Analyze a task and you see how it can be made easier. Why, adding a feature seems so virtuous...

Every student takes courses on the computational aspect of computers. But there are very few courses on the problems faced by the user...

A couple of takeaways for me:

Design is really an act of communication, which means having a deep understanding of the person with whom the designer is communicating

When simple things need pictures, labels or instructions, the design has failed

Anyone who creates something for human use or consumption, which describes those of us in software development, would benefit from the ideas and explanations in The Design of Everyday Things

Ouch!

2011-02-02T12:29:00.000-08:00

Seen on a t-shirt:

More people have read this t-shirt than have read your blog....

GOOOOALS, 2010 Review

2011-01-01T08:47:00.000-08:00

I started blogging a little over a year ago and one of my first posts was a list of goals for 2010. Now that it's the end of the year, let's see how I did.

2010 goal 1: Read a book a month.

I was close with 10. Here's what I read:

Understanding the Professional Programmer and Becoming a Technical Leader - Gerald Weinberg

Cube Farm - Bill Blunden

Software Craftsmanship - Pete McBreen

Secrets of the Rock Star Programmers - Ed Burns

The Passionate Programmer - Chad Fowler

Apprenticeship Patterns, Guidance for the Aspiring Software Craftsman - Dave Hoover and Adewale Oshineye

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency - Tom DeMarco

Waltzing with Bears - Tom DeMarco and Timothy Lister

Professional Software Development - Steve McConnell

I did start another book: Write Great Code, Volume 1: Understanding the Machine by Randall Hyde. This one is challenging to get through due to it's complexity and technical nature. I will complete it this year and get to the second volume!

2010 goal 2. Finish the exploratory/learning "Rental Management System" (RMS) I've started writing in Java.

Not quite on this one. My initial problem domain proved to be a little too complex in that I was spending more time on understanding the requirements rather than focusing on the code, so I switched to a simpler domain: a book library. I was able to complete this system and I'm happy with the result. The UI is not too fancy but functional. More importantly, I really learned a lot by rolling my own persistence and error handling/logging.

2010 goal 3. Learn a new programming language by rewriting the RMS in that new language.

I really had fun with this one. I rewrote the Java/JSF book library in Groovy/Grails. The Grails framework is fascinating and I love its abstractions.

2010 goal 4. Write two blog posts a month.

Yes! I got to 34:

5 posts in January
3 posts in February
3 posts in March
5 posts in April
2 posts in May
4 posts in June
1 post in July
1 post in August
2 posts in September
1 post in October
5 posts in November
2 posts in December

5. Take some sort of multi-day software development training.

Yes! I was able to attend the following:

January - 10x Software Engineering at Construx Software

April - Seattle Code Camp

September - Pacific NW Software Symposium

All in all, I'm happy with my accomplishments and I'm looking forward to continued professional development in 2011!

Professional Software Development

2010-12-31T13:27:00.000-08:00

Prior to reading Professional Software Development by Steve McConnell I thought about Software Development as a career, but not as a Profession. And, although I'm constantly looking for ways to solve the quality and schedule problems that plague software development projects, I never really thought about whether or not a Profession's advantages would/could help solve the problems.

After reading this book I'm looking at software development in a new light.

The author makes a great case for a Software Development Profession, and explains how it can lead to predictable, controllable, economical and manageable projects. He details both the problems and the solutions, and he presents the benefits in a compelling way.

I don't see why software development can't be a profession like Medicine, Law, or Accounting but there are a few challenges:

1. The immaturity of computers and software (which stands out when you compare it to Medicine or Law)

2. The discounting or overlooking of quality, innovation and improvement and their associated benefits

3. The fact that "good enough" software is so prevalent

My favorite parts of the book:

The considerable discussion of "code and fix" development and why it's a common problem

The clear and concise explanation of Fred Brooks article: No Silver Bullets - Essence and Accidents of Software Engineering

The chapter dealing with personnel or human-oriented factors

Anyone concerned about successful software development will gain valuable insights from the book. In addition, the entire industry would benefit by thinking about software development in terms of professionalism.

Quote of the Day

2010-12-21T21:18:00.001-08:00

Systematic design excluding intuition yields pedestrian follow-ons and knock-offs; intuitive design without system yields flawed fancies. - Frederick Brooks, Jr. in The Design of Design

Paradigm Shifting (again)

2010-11-20T09:09:00.000-08:00

I began my software development career working with Cobol so I was one of those that had to struggle through the OO paradigm shift.

Now I find myself shifting again. This time to the concept of "convention over configuration" and frameworks that abstract the mundane parts of software development like persistence and security.

I love abstractions. I took it as a complement when a co-worker in a design session said I was "too abstract." So I love how the new frameworks aid in the design and creation of loosely coupled systems.

Lately I've been working in Groovy/Grails and I'm really enjoying it. It's amazing how much less code you have to write to create a Groovy app with Grails, as compared to Java. You can literally get a web app created and running in a matter of minutes.

Slack

2010-11-14T17:05:00.000-08:00

Much of my software development experience has been with "hurry up" organizations where the highest priority was getting work done quickly. It was no surprise (to me anyway) that these organizations weren't very effective.

So I was happy to find a Tom DeMarco book that presents a better way: Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency - A Handbook for Managers, Entrepreneurs, and CEOs.

Slack is a small book that packs a quite a punch. It's all about efficiency. In part, "...a diatribe against efficiency." It focuses on why "hurry up" and "work harder" are wrong and why efficiency schemes, mandates and initiatives reduce, not promote, effectiveness. The book's position:

It's not that "efficiency doesn't matter at all", it's that "it doesn't matter most of all"

In a way it concerns me that there is a need for this book. Do we really need to be reminded that effective is better than efficient? That knowledge workers have skills, talents and experience that are not exchangeable? That humans are not efficient the same way machines are?

Slack is:

Building a capacity to change into the modern enterprise
The degree of freedom in a company that allows for change and innovation
Room to think, innovate and reinvent

Many have written about the need for innovation. Google CEO, Eric Schmidt, captured a key concept:

The Internet has put abundant information and powerful tools in everyone's hands, innovation is often driven from the bottom up. More than ever, innovation is disruptive and messy. It can't be controlled or predicted. The only way to ensure it can flourish is to create the best possible environment - and then get out of the way. Its a question of learning to live with a mess.

In a lot of companies it's efficiency - control and predictability - vs. innovation - disruptive, messy and can't be controlled or predicted. Which side are you on?

In my experience the "hurry up" organization shrinks schedules to provide a necessary "sense of urgency." I've always bristled at that tactic - that pressure improves performance and that maximum performance can occur only in the presence of maximum pressure. A great quote from the book (from Tim Lister) succinctly counters the concept: "People under time pressure don't think faster."

I find myself in agreement with the author and the book paints an accurate and valuable picture about the state of software development.

Some food for thought:

Knowledge work is a card game where all the cards are wild.

The more efficient you are, the harder it is to change.

The missed schedule indicts the planners, not the workers.

Good companies excel in the creative use of slack. And bad ones can only obsess about removing it.

The more successful a company is in extracting every bit of capacity from its workers, the more it exposes itself to turnover and attendant human capital loss.

Projects in which the schedule is commonly termed aggressive or highly aggressive invariable turn out to be fiascoes. "Aggressive schedule," ...is a kind of code phrase - understood implicitly by all involved - for a schedule that is absurd, that has no chance at all of being met."

A good contract requires slack. If a vendor commits to X by a given date, you act to your own peril to accept that commitment unless you can see that the vendor has left itself sufficient slack.

When the new automation is in place, there is less total work to be done by the human worker, but what work is left is harder.

When there is neither time nor staff to cope with work that runs more slowly than expected, then the cost of lateness is paid out of quality.

Change can't happen without risk, and risk-taking is only possible in an environment that can be tolerant of at least some failure.

Learning and reinvention take time. If people are too busy doing the work they will never have the time to learn new ways to approach it.

The earliest date by which the work could conceivable be done makes an excellent goal but an awful schedule.

Give your people time to think - innovation and reinvention will follow.

Quote of the Day

2010-11-13T09:36:00.000-08:00

Leadership is the ability to enroll other people in your agenda - Tom DeMarco

Quote of the Day

2010-11-11T16:54:00.000-08:00

People under time pressure don't think faster. - Tim Lister

Developer Bees

2010-11-07T08:18:00.000-08:00

Came across a great post today comparing developers to bees that really hit the trifecta - funny, insightful and, based on my experience, so true.

It explores a basic premise:

The environment that nutures creative programmers kills management and marketing types - and vice versa.

The development product - the software - is often the reason a company is hatched. But as time goes on the software loses it's importance and is treated as a commodity. This is so wrong because, in addition to providing business value, creative and quality software provides strategic value. It really can be a company's competitive advantage.

But only if development keeps its equal share of importance and influence.

Waltzing with Bears

2010-10-03T20:59:00.000-07:00

I've seen many software projects fail because risks weren't addressed. So I was interested to see what Tom DeMarco and Timothy Lister had to say about risk in Waltzing with Bears - Managing Risk on Software Projects.

Software projects are all about risk. How do you deal with the risk? Do you welcome it? Embrace it? Search it out? Or do you avoid it?

Waltzing with bears explores these questions. The right answer, according to the book, is to take on risk in a mature, honest and informed manner. Because where there is risk there is reward. And ultimately, competitive advantage.

But dealing with risk is definitely not easy to do, or do well.

The book defines risk management as the process of thinking out corrective actions before a problem occurs. The opposite of risk management is crisis management, or trying to figure out what to do about a problem after it happens.

The prologue begins with a story to focus on how beliefs are acquired, and how beliefs can drive the approach to risk. Do you honestly earn your beliefs in patient investigation? Or do you simply stifle your doubts?

To manage risks you must define and categorize them and not just make them disappear by ignoring them.

The book explores 5 basic parts of risk management:

1. Understand why it's important to do it
2. Explore when it's appropriate to not do it
3. Decide on much risk to take on
4. How to go about it
5. Know whether or not it's working

The book also provides a simple plan for risk:

Categorize it up front
Plan for mitigation
See it coming
Deal with it

The book is full of practical advice to make the job of risk management a whole lot easier.

My favorite quotes from the book:

"Risk management is not the same as worrying about your project."

"Risk management is project management for adults."

"When a seven-month project ends up taking twelve months, angry upper managers seldom blame the schedule; Instead, they blame those who were supposed to make that schedule - no matter how ridiculous it was - into reality."

Precisely stated costs and vaguely hinted-at benefits make a travesty of cost-benefit analysis. More importantly, they also make sensible risk management impossible.

Justification for the death march always takes the form of project importance: This effort is so essential that it requires the utmost of project personnel. But there is a bit of a conundrum built into that statement. If the project is so essential, why can't the company spend the time and money required to do it properly?

Pacific NW Software Symposium

2010-09-19T18:08:00.000-07:00

This weekend I attended the Pacific NW Software Symposium - part of the No Fluff, Just Stuff tour.

My goal was to get some clarification, or concreteness, on the concepts I've been collecting in my head: Cloud, Google as a dev environment, Grails, NoSQL, etc. I haven't kept pace with the industry and I have a nagging suspicion that I need to change the way I think about development.

Overall I had a great time and learned a lot. The venue and amenities were fine, although the rooms were a bit cramped at times. This was a full three day event (Friday, Saturday and Sunday) and much to my surprise, I wasn't "full" on the last day. I could have kept going. But now I need a month off to pursue the all the ideas I've accumulated over the weekend.

The first day was about doing. I attended 3 sessions presented by Jeff Brown:

Enterprise Applications With Grails
GORM Inside and Out
Building Twitter with Grails in 90 Minutes

I didn't have any prior exposure to Grails, which is a framework for building CRUD web apps using the Groovy language. Grails is powerful and easy to use. It abstracts and automates the common tasks of web app authoring. During the session I was able to quickly set-up and use Groovy/Grails and by the end of the session I had a simple web app running.

One of my 2010 goals is to port my "breakable toy" JSF/Java web app to a new language. Prior to this session I was thinking about Ruby as the new language. After this session I think I'll give Grails/Groovy a try.

GORM is Grails Object Relational Mapping. It sits on top of Hibernate and makes it easy to deal with persistence.

In the final Grails session we were able to create a web app with the following functionality (in just 90 minutes!):

login / logout
enter text on web page
save in db
query db
display entries saved in db
caching
post / consume JMS messages

Prior to this introduction and use of Grails I didn't really understand how frameworks make development easier. But the sessions gave me an "aha" moment in understanding the abstraction of authentication, data input/display, persistence, etc.

The second day was mostly about thinking. I attended the following sessions:

Complexity Theory and Software Development by Tim Berglund
Decision Making in Software Teams by Tim Berglund
Pragmatic Architecture by Ted Neward
Architectural Kata Workshop by Ted Neward

It was interesting to discover the overlap between the books I have been reading and what was presented in the first two sessions. Seems like I gravitate towards human interaction topics. All of these sessions got my mind going. One of my biggest challenges is affecting some kind of change that can eliminate the downside of focusing strictly on the technical side of software development.

The third day was a mix of thinking and doing. I attended the following sessions:

Cloud Computing Boot Camp on the Google App Engine by Matthew McCullough
GAELYK - Lightweight Groovy on the Google App Engine - Tim Berglund
Busy Java Developer's Guide to MongoDB - Ted Neward
Hacking Your Brain for Fun and Profit - Nathaniel Schutta

Learning about the Google App Engine and MongoDB forced me to alter and expand my software mindset. Thanks, I needed that!

The only session that didn't rate excellent with me was the Architectural Kata Workshop. I was hoping to pick up some architecting skills but because of the attendees' skill variance and lack of domain knowledge of the kata, most of our time was spent trying to define and understand requirements.

Overall, I'm very satisfied and glad I attended. I'm looking forward to next year's event. The main takeaway for me: Don't think "Java" anymore, think "languages of the JVM."

Quote of the Day

2010-09-12T09:21:00.000-07:00

"The difference between strategic thinking and drift is a matter of whether the key choices are made mindfully or mindlessly." - Tom DeMarco in Slack

Quote of the Day

2010-08-18T22:07:00.000-07:00

"While it's possible to specify a product ambiguously, it is not possible to build a product ambiguously." - Tom DeMarco and Timothy Lister in Waltzing with Bears

Becoming a Technical Leader

2010-07-10T22:38:00.000-07:00

I picked up Gerald M. Weinberg's Becoming a Technical Leader: An Organic Problem-Solving Approach because I'm interested in the intersection of leadership and technology, having seen the results of a lack of leadership.

Like all of GW's books, this book made me think and reflect personally. In this case, on my own leadership style (or lack thereof).

The book is based on the knowledge GW has acquired from 20 years of running leadership workshops. One constant about Gerald Weinberg: He is a master storyteller. At times I forget that I'm reading a technical book.

The book begins with a premise - leadership is familiar, but not well understood - and provides a basic definition:

Technical Leadership is the process of creating an environment in which people become empowered to solve problems.

The book presents some interesting observations about technical leaders:

They are not the pure technicians produced by the engineering and science schools, nor are they the conventional leaders trained in the schools of management.

They have a rare combination of technical expertise and leadership skills

They have a concern for the quality of ideas and want everything to be the best

They have a nurturing process and do not take charge of people's lives

GW humorously describes his initial desire to avoid leadership:

...to make doubly sure I would never have to deal with leadership questions, I chose a career in computer software.

He then goes on to describe how he fell into leadership, which is how I see a lot technologists become leaders:

Whenever I did a reasonably good technical job, my co-workers learned to respect me a bit more. Because they respected me, they looked to me for advice, for leadership.

The books presents and describes leadership within two models: Linear, where one effect stems from one cause, and organic, where an event is the outcome of hundreds of other factors, including the passage of time.

The linear model is focused on leading people and allows for dealing with people quickly and efficiently. But the linear model tends to place individuals into categories or roles, or what people should be. This results in a tendency to view leadership as simply a role of issuing threats and doling out rewards. Also, the linear model does not handle complexity which is prevalent in most critical events involving people.

The organic model defines people in terms of their uniqueness and allows different people to find a common basis for working together in complex situations. Instead of leading people, the organic models focuses on leading process. The organic model is useful in technical work because it takes complexity and innovation into account. The organic model focuses on empowering people.

Technical leadership fosters an environment where change can occur. Change in other people, change in working groups, and change in organizations. In order for change to occur the environment must contain three factors: motivation, organization and innovation.

The best technical leaders use these three factors to create a problem-solving leadership style that concentrates on three major areas:

understanding the problem

managing the flow of ideas

maintaining quality

The book does a good job of describing both the obstacles to motivation, organization and innovation, and ways to promote them. It also describes how to transition to leadership, where you'll have a whole new set of rules but no rulebook.

A couple of quotes that stood out for me are:

Leaders that don't care about people don't have anyone to lead, unless their followers don't have a choice.

Leaders have twice as many areas to criticize - both content and process.

The part of the book that I enjoyed the most is the epilogue where GW offers some really good advice on the need to think about whether or not you want to be a leader.

It takes many leaders to create software that is successful. And whether or not you have Leader in your title this book will help you become a problem solver and someone that others look to for advice and leadership.

End of a Chapter

2010-06-19T10:00:00.000-07:00

For the past couple of years I've been examining my personal and professional goals.

This blog is a result of that examination and the realization that I need to take charge of my career.

Another thing I realized is that I had outgrown my current position. My goals and vision didn't match those of my employer for the last 8 years.

So, one thing led to another and the result is that I'm opening a new employment chapter next week.

I'm looking forward to the challenge and the opportunities to come.

Apprenticeship Patterns

2010-06-19T07:40:00.000-07:00

In my investigating on what it means to be a professional programmer I came across a great on-line book that combines patterns and software craftsmanship:

Apprenticeship Patterns, Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye.

Like many of the blogs, books and sites I've been reading lately, this book reinforces my thoughts that I need to move on, and become proactive about taking my developer career to the next level.

The book's stated goal is

....to share solutions to the dilemmas that are often faced by inexperienced software developers....the dilemmas that we focus on are more personal, concerning your motivation and morale.

Part of the conclusion really resonates with me:

Software development is a craft precisely because we don’t understand it well enough to make it a codified discipline like science or engineering. Despite the best efforts of groups like the Software Engineering Institute and the Agile Alliance, our field is still one where individual skill is often the most significant determining factor in a project’s success. When we use the word skill, we don’t just mean how much computer science you know or the effectiveness of your development process or how much experience you have. We mean the union of all the things it takes to deliver working software.

The book contains 34 patterns, or common solutions to common problems, that got me to focus on my feelings about where I am professionally. I fit some of the books insights:

Restless

You need to grow your skills, your confidence, and your portfolio of successful work. You feel the need to challenge yourself with bigger things. This may involve bigger projects, larger teams, more complex tasks, new and business domains, or new places.

You are beginning to realize how little you know

As you are introduced to the vast reaches of your ignorance you are overwhelmed.

Need to collaborate face-to-face with some exceptional software developers.

“Just” a software developer.

Current environment stifles your passion for the craft.

You find that your vision of yourself is not in accord with your employer’s vision for you, and there doesn’t seem to be a way to reconcile the differences

Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow.

You are months or years into your apprenticeship and you find yourself discouraged by the culture of your development organization.

You find yourself stranded without mentors and in an atmosphere that seems at odds with your aspirations.

There's a lot of great information in the book and I'm going to keep it handy in order to keep up my motivation, morale and learning.

Interruptions

2010-06-02T20:31:00.000-07:00

In a recent "lunch and learn" session our assignment was to take on a code kata.

I worked on it at home and got buried in it, what Tom DeMarco calls "flow time." So much so that when I stopped with a solution, two hours had passed. I know it's a common pattern among developers: you're so focused that nothing else matters. Developers are knowledge workers and thinking is the main part of our jobs.

So, what's your work environment like? How long can you focus? How many interruptions do you get in a day? How many of those interruptions are even related to the task at hand?

Gerald Wienberg says in Understanding the Professional Programmer that "...programming computers is by far the hardest intellectual task that human beings have ever tried to do. Ever." If so, (and I think it is) then the ability to focus should be a given.

It's too bad that a quiet, interruption-free development environment is so rare.

Quote of the Day

2010-06-01T21:09:00.000-07:00

"Many project managers really don’t care if the end product is successful, and many times a project manager doesn’t really care if the product is useful. They are given a spec and are told when the product is needed by. Project managers maximize efficiency and control for change." - Trapper Markelz in The Difference between Project Management and Product Management

Quote of the Day

2010-05-25T21:58:00.000-07:00

"Your grandmother may have told you that practice makes perfect. She was wrong. In fact, practice makes permanent. So be careful what you practice...." - Dave Hoover and Adewale Oshineye in Apprenticeship Patterns, Guidance for the Aspiring Software Craftsman

Quote of the Day

2010-05-20T22:07:00.000-07:00

"...our task in a software development project is to manage the
incompleteness of our communications" - Alistair Cockburn

Quote of the Day

2010-04-25T08:58:00.000-07:00

"An error detected in integration is not an integration error." - Alan Shalloway

Seattle Code Camp

2010-04-19T21:09:00.000-07:00

I attended Seattle Code Camp this weekend. It was a great event. The venue, one of the buildings in the new Microsoft Commons complex in Redmond, was awesome and the logistics/amenities were excellent.

My only complaint is that the sessions were mostly focused on Microsoft technologies (SQL Server, ASP.Net, C#) - there weren't any Java/Oracle specific sessions. Having said that, I did learn something in each session I attended and I'm going to follow-up by writing some jQuery and Ruby code.

Sessions I attended:

jQuery for the Unconvinced - Scott Koon
A look at the jQuery JavaScript library.

Fast… Faster… FASTER! - Ade Miller
Using the latest parallel programming features of C#, F# and C/C++ to improve performance.

Mind Mapping by Hand - Justin Bozonier
A look at the presenter's maps to understand how to be a more effective note taker.

Ramp Up Your Presentations! - Arnie Rowland
How to succeed as an outstanding presenter.

Secure Authentication and Session Management - Don Ankney
A look at how you can protect your user’s private data even if the application is compromised.

Dependency Injection and Library Design - Chris Tavares
A look at how Dependency Injection can be applied in a library.

A Journeyman Programmer Pilgrimage - Liam McLennan
What is the Software Craftsmanship movement? The highs and lows of a journeyman programmer's travels across the country.

Ruby for Newbs - Bobby Johnson
A basic look at the Ruby language.

Quote of the Day

2010-04-16T20:52:00.000-07:00

"Don't accommodate an impediment." - Alan Shalloway

More Better

2010-04-11T08:47:00.001-07:00

Recently Jeff Atwood's Coding Horror blog had a great post about User Interface and Fitt's law.

As mentioned in the blog Fitt's Law has a couple of basic tenets. One is
Make clickable areas as large as you can. Larger targets are easier to click on.
Common sense, right?

I was thinking of this tenet when using facebook's UI control for accessing additional posts at the bottom of a screen. The facebook control looks like this:

It looks like a big button but the "Older Posts" text is the only clickable area. There's that whole big button-like area but the user has to hit the tiny text target!

Until I read about Fitt's Law this tiny target issue was just a nuisance. But now when I compare it to other sites it sticks out like a sore thumb. For example, twitter's UI control for accessing additional posts makes it easy and obvious:

Just hit anywhere in the giant more button.

Thats "more better!"

Quote of the Day

2010-04-09T21:05:00.000-07:00

There's nothing I wouldn't do, including doing nothing - Wood Beez, Scritti Politti

Secrets of the Rock Star Programmers

2010-03-29T20:21:00.000-07:00

In keeping with my quest to learn I picked up Ed Burns' book Secrets of the Rock Star Programmers. The questions in the introduction piqued my interest:

How in the world can I keep up with all this information coming at me every day?

What can I do to ensure that I keep bringing value to my employer or client and to help ensure continued career success?

What will the practice of software development look like in ten year's time?

How do I know where to invest time and effort in stewarding my skillset?

The claim on the back cover, "Find out what it takes to push your programming chops to the next level and design killer software by getting inside the minds of today's rock star programmers", is a bit over the top but it was great to get a little insight into the thoughts of some of the industry "suns" that I follow.

After finishing the book I'm struck by a couple of things: the programmers interviewed in the book, the rockstars, are mostly (much) younger than me and mostly less "experienced" than me. Damn! - I'm older, I have more years in the industry but I'm just another coder.

I don't need to be a rockstar but it would be great to be recognized as someone who can deliver well designed, high quality applications. Or as Rod Johnson (one of the Rockstar programmers) said, quoting E.M. Forster, "...earn the respect of people that I respect."

Some other quotes that stood out for me:

Rod Johnson:
I think if you consistently find that the right thing is hard to do, there's something wrong. The right thing should be the right thing partly because it's easy and natural to do. If the right thing is unnatural, that is kind of an environment smell. It's beyond a code smell. It's telling you something.

...about 90 percent of the work that I've seen where people are optimizing code in a business application is a complete waste of time, and they're simply making the application more bug-prone...prove to me that it's a problem before you spend any time making it faster.

Hani Suleiman:
Be skeptical...There's too much eagerness: "let's follow this new approach," "let's do this new thing," and so on...Everyone looks at the upsides; no one looks at the downsides.

Floyd Marinescu:
Ultimately, we're solving business problems - I think a lot of developers need to remember that the purpose of the job is to build applications [that are] useful to users. The software is only as good as how it serves the functional and non-functional requirements of the application.

Dave Thomas:
Many IT professional don't have the concept of "component" or "system." It's just not how they think about the world. This is one reason why enterprise business objects and business architectures often run into difficulty. These organizations are frequently driven by a project culture versus a product culture; hence, components, reuse, and other long-terms investments have little value. Trying to do component engineering in a project culture is very, very difficult because the driver is "How does this help me get my application done faster?" This is always in conflict with any kind of object architecture, business objects, etc.

The Passionate Programmer

2010-03-14T19:00:00.000-07:00

If your software development career needs a "kick in the pants" then you need this book. I needed this book.

I ordered the book because felt my passion for quality software development growing and I wanted to get another take what it means to be passionate about programming.

Ouch! Yes, my thinking is aligned with the author's but my actions don't reflect my passion. I was, like the book says, just floating down the stream of my career, letting the current take me where it may.

For me, the preface alone was worth the price of the book:

If your life is primarily consumed by your work, then loving your work is one of the most important keys to loving your life. Challenging , motivating, rewarding work is more likely to make you want to get up in the morning than dull, average tasks....if you don't do your job well, a large amount of your time will be spent feeling inadequate or guilty over not performing at your best.

This book isn't about struggling to maintain the level of mediocrity required not to get fired. It's about being awesome. It's about winning.

The book is also full of practical advice and "Act on It!" sections with specific, concrete steps to take to advance your career.

Some gems that hit a little too close to home:

It drives me crazy to ask people whether they've seen or used certain not-quite-mainstream technologies only to hear, "I haven't been given the opportunity to work on that" in return. Given the opportunity? Neither was I. I took the opportunity to learn.

Fear-driven career planning is more likely to land you in a cubicle farm for the rest of your life than on the path to greatness. Sure, it's safe, but it's no fun.

Passion leads to excellence. And without fun, there's unlikely to be any passion in a software job.

You have to be passionate about your work if you want to be great at your work. If you don't care, it will show.

You have to start by realizing that even if you're on the bleeding edge of today's wave, you're already probably behind on the next one.

Don't hide behind the shield of mediocrity.

Change is not only possible in your career but necessary.

No longer will I, as the book so succinctly states, do an excellent job at delivering a career to myself that I don't want. I'll continue to work towards becoming a Passionate Programmer - I definitely don't want to end up in a "technology hospice" where all I do is help old systems die comfortably and with dignity.

Similarities Between Interaction Designers and Agile Programmers

2010-03-01T20:59:00.000-08:00

I've been a fan of Alan Cooper ever since I heard him speak at the Puget Sound SIG on Computer Human Interaction in 2005. He's one of the "suns" I identified in an earlier post. He's insightful, outspoken and always thought-provoking.

I came across an interview - Similarities Between Interaction Designers and Agile Programmers - he gave at Agile 2008 and once again I was captivated. If you like Alan you'll love this interview. If you don't know of Alan you're in for a treat.

I like Alan's focus on quality and the need to define the problem before creating the solution. Some quotes that stood out for me:

The fundamental goals of Agile programming are to let programmers who are knowledge workers get to the core of their motivation and the core motivation of all knowledge workers is to do good work. And I think there are a lot of people around the fringes of the Agile movement who don't get that yet and who think that Agile is about productivity, and it is not about productivity, I think that productivity is a byproduct, but if you set that up as your goal you will fail

[agile's core is] introspection, it's doing it and then make sure we did it right, and then pay close attention to what parts of it we didn't do right, and bringing some questioning analysis to that so to increase the proportion of rightness in what you do in the future. So the essence of Agile is reflective, it's transformative and it's on going, and it's self correcting.

The economics of software are qualitatively different than the economics of industry...In software there is no on-going cost, there is no manufacturing cost there is no material costs, so driving cost down just reduces the desirability of the product...What you want to do is create your number one goal, to say what do we have to do to elevate the quality, the desirability, of the end product. And when you worry about costs, you hurt that. And one of the great things that I see in Agile is an understanding that says "Hey mister businessman, stop worrying about the costs and start worrying about the quality"...don't start thinking about delivery times and don't start thinking about costs reduction and don't start thinking about ROI, think about the quality because that's why we are all playing this game.

And one of the great weaknesses in the process is that there is nobody figuring out what the problem is and what the solution is. There is lots of good people figuring out how to build the solution, and there is lots of people figuring out actually building the solution....it is considered normal in the software business, that building the solution to the wrong problem is normal, and you will go on from there.

Cube Farm

2010-02-22T20:46:00.000-08:00

The title of Bill Blunden's book, Cube Farm, piqued my interest because at times I've been one of the many development resources housed in cubes. And although my experiences don't live up to the authors, I was able to commiserate with the narrative.

I enjoyed the book. It was humorous and mirrored some of my experiences. I found quite a bit of food for thought despite the lighthearted approach. In fact, the book can be treated as one giant software development case study.

The back cover sets the stage:

Truth is stranger than fiction, especially when it comes to the workplace. Consider this book a reality check for anyone preparing to enter the work force, and a survival guide for those entangled in their own personal version of Office Space.

The preface lays out the ground rules:

The reality is that competition not only exists between corporations but also inside of them. For all the cloying praise that's heaped on the concept of teamwork in business schools and by motivational speakers, in many cases your coworkers are also your opponents ... People compete for better projects, better resources, promotions, pay raises, and nicer offices.

The chapters introduce the cast of characters:

Houdini
Gigolo
Godfather
Long John Silver
Last Mohican
Mad Prophet
Puppet Master
Shill
Wax Artist

The physical setting, the cube farm, adds to the theatre:

Rows upon rows of people laboring under the unremitting glow of fluorescent track lighting. If you listen carefully, you could hear the employees groan as the inverted pyramid of management bore down upon them. Being passive and obedient workers, they were milked for all they were worth.

And the authors personal story completes the saga:

....I participated in a smorgasbord of failed projects. The failures were all caused by political, rather than technical problems: in fighting, empire building, backstabbing, nepotism, witch hunts, collusion, sabotage and duplicity, just to name a few. I honest believe that some software companies ... are their own worst enemies.

A grim quote from the book is a coworkers reply to the author's lament about his multiple failed projects:

It's just the nature of the beast. I'll tell you something. I've been in software for over 30 years, and out of those 30 years I've only shipped one product. This is just the way things are.

If nothing else, the book got me to reflect on why this shouldn't be the way things are.

Software Craftsmanship

2010-02-07T12:39:00.000-08:00

I've been hearing and reading a lot about software development as a craft so I picked up the book Software Craftsmanship by Pete McBreen.

After reading the book I realized that I have been gravitating in the craftmanship direction for some time. It was good to get a different perspective that reinforces my thoughts. Like the author I sense that the current state of software building is not working.

The author's motivation for the book was his acknowledgment that it was time to stop complaining about the state of software development and write about the issues. The book is a "call to arms" and the author states that "we must insist that developers really know their craft before we trust them to create systems for us or with us." It's hard to disagree.

The book does a good job of defining the traditional development approach - Software Engineering - and explains why it doesn't work and why it is not the right choice for Craft projects. It then goes on to present the case for Software Craftsmanship.

Some of the main points of software craftsmanship that I like:

People, not processes, are the focus

Teams are made up of skilled resources - apprentices, journeymen and craftsman - constantly learning from each other

Software is long-lived and treated as capital

The useful life of applications is maximized because the cost and risks of replacement are immense

Developers have unique skills and are paid to think

Developers have a personal commitment, take pride in their work and "own" their work

Developers need to practice - learning is hands-on

I believe Software Craftsmanship will be embraced by shops that are open to change and improvement, but, unfortunately, will be a hard-sell in shops that are all about productivity.

Where Do You Start?

2010-02-03T21:02:00.001-08:00

Why write software? To solve a problem of course.
Simply stated, software is used to model the real world, or problem domain, in the computer to solve a real world problem.

A key question that needs to be answered initially is, “Where do you start?” More specifically, do you start on the Problem Domain side? On the Solution side? Somewhere in the middle? I've always leaned towards the “Problem Domain” side – seems to me that it’s the right answer in an agile/OO world.

Jon Kern at technicalDebt.com summed up my thinking in a post titled Good Judgment is Agile:

...The key to development is separation of concerns

the core is the problem domain built to support the requirements.

get this wrong, nothing else in the app matters. nothing.
not the UI/UX.
not the 5th normal form DB.
not the worlds most articulate UML models.
not the worlds best cruise-controlled, TDD, 100% test coverage.
not the best joshua bloch-/steve mcconnel-blessed code.

this core generally transcends UI, database, and even the language chosen to code the app. In other words, the "problem domain" reflects the relatively stable "business" world. I know it sounds trite, but despite all our wonderful software advances from green screen to now, the world of mortgage/insurance/banking has changed little, fundamentally, or relatively.

the app is all about the "business" needs
the User Experience/UI is a separate thing

The persistence is a separate thing

Let’s say that there is a business requirement for doodads and thingamajigs:

A doodad and a thingamajig must be captured while creating a …

I often see a start on the solution side that goes something like this:

Doodads and thingamajigs, hmmm. They have a code and description so they’re just simple reference data. We’ll use a ReferenceDataWidget to supply a list of reference values from the database.

On the problem/solution scale “ReferenceDataWidget”, “list” and “database” fall on the solution side.

Why is this a bad thing? Because there isn’t any representation of the problem domain, i.e doodad, and there isn’t any means for abstraction of the problem, which is necessary to reduce complexity. The client of this solution will be coupled to a specific solution implementation.

Steve McConnell, in his classic book Code Complete, addresses this abstraction and complexity when he talks about Programming in Terms of the Problem Domain:

…Another specific method of dealing with complexity is to work at the highest possible level of abstraction. One way of working at a high level of abstraction is to work in terms of the programming problem rather than the computer-science solution.

So how about something like this:

The client of this solution will be coupled to an abstraction, Doodad, which can then be implemented (or re-implemented) in any fashion. This decouples the problem domain and the solution, which allows the solution to change without affecting the client.

To Optimize, Or Not...

2010-01-27T20:49:00.000-08:00

A recent code review spawned a spirited discussion about list creation and whether or not to set an initial size when the number of elements is known.

In Java an array that holds 3 widgets could be create a couple of ways:

List list = new ArrayList();

list.add(new Widget("alpha"));
list.add(new Widget("beta"));
list.add(new Widget("gamma"));

or

List list = new ArrayList(3);

list.add(new Widget("alpha"));
....

The spirited part of the discussing boiled down to the question, "Which way is better?"

The second option certainly appears better from a performance standpoint. It's logical: Letting the code create the list at the exact size needed is faster than a list that has to grow as it is populated.

On the other hand, as the "premature optimization" camp believes, writing code that is easy to understand/extend/modify should be the overriding goal - you worry about optimization when you a have a specific, quantified problem - and the second option creates one more thing for a dev to keep in mind as he works the code. That is, six months from now when a new entry is added to the list the initial size will have to be updated. Any bets on the chance that the update will be missed?

And then there's the unknown: What does the specific compiler and/or the underlying execution do with the statement
"List list = new ArrayList(3)?"
Could there be some built in optimization that would be overridden by setting an initial list size?

I was pretty vocal about the need to avoid premature optimization but I didn't want to just pontificate. I decided to get some metrics on the specific case we reviewed and the result was that using an unsized list took just a fraction of a second (6/100ths) longer.

I then ran 4 sets of additional tests comparing how long it takes to add simple objects to an unsized list and a sized list. The tests used 1 thousand, 10 thousand, 100 thousand and 1 million elements.

The results showed that until the element count reached 100 thousand there was no time difference. And at 1 million elements the typical time difference was only 120 milliseconds:

140 milliseconds to add to an unsized list
20 milliseconds to add to a list with an initial size of 1000000

In other words, there was only about 1/10th of a second difference when dealing with 1 million elements. An interesting discovery is that it took 2/100ths of a second longer to create the sized list.

So, which way is better? As always, the answer is "it depends!" This example is just a nit, but design/coding decisions have a cumulative effect so it's important to be conscious of the trade offs.

Books Can't Teach

2010-01-15T21:22:00.000-08:00

A while back I bought Martin Fowler's book, Patterns of Enterprise Application Architecture. I had grand learning plans and was prepared to take it all in.

I read the introduction and loved it - great information that made sense. I then read the narratives. They made some sense but the information was complicated and full of references to unknown patterns. The love was fading. Then I came to the actual patterns. Huh? It was like a foreign language. I was so confused and disheartened that I sent the book back.

As time passed I had a gnawing suspicion that there was some important information in that book that I really should know (or at least know about). And then a funny thing happened.

I was playing around with my little web app that I use for learning and I was rolling my own object/relational layer. I had a few design theories but every time I started to make progress some detail came up that made me rethink my approach. I realized that I could use some outside help. And then I remembered the book. I borrowed a copy and started reading.

Active Record. Hmmmm. Data Mapper. Interesting. Unit of Work. Ok. Identity Field. My head was nodding.

As I was pondering the patterns (the many patterns) I realized that they made sense. I had a problem context and in this context some of the patterns jumped out as possible solutions.

So, in addition to learning some new patterns I also learned an important lesson: Books can't teach but they certainly make learning easier.

Testing the UI and Business Logic

2010-01-10T21:26:00.000-08:00

Michael Feathers has a post up about UI Test Automation tools and the gap between the dream and the reality. The post got me to focus on some thoughts/concerns I have about testing and the UI.

I've never understood the (un)intentional coupling of the UI and business logic. I agree with Feathers:

...testing your full application end-to-end through a UI Testing tool...couples some of the most important tests in your system to one of the most volatile parts of it. It’s easy for us to see business logic as volatile, but really, the UI is the thing which twists and ripples in the winds of change.

I've seen this coupling also create the situation where, in order to test comprehensively, every single possible data/behavior combination must be initiated from the UI. Seems to me that the testing needed at the UI level is does the UI meet the API of the layer below it? Of course, that's only possible if the UI and the lower layer are decoupled.

Understanding the Professional Programmer

2010-01-10T14:28:00.000-08:00

Just finished Gerald Weinberg's Understanding the Professional Programmer. The book is a collection of essays and is an easy read. The essays are short, informative and to the point.

If the author wasn't Gerald Weinberg (GW) I may have passed on this book based on the title, thinking it was about how non-programmers can understand programmers. But the book is really about how to be a successful programmer.

I enjoyed the book. This is true for almost all of the books I've read by GW - seems I either enjoy them or don't understand them.

This book I definitely understood. A lot of the material hit home and caused introspection. Although the book was published in 1988 its concepts are timeless. In fact, as I read the book I recognized themes that I've seen explored in contemporary books, such as code quality, productivity measurement and constant learning.

The book presents the following definitions and examines them in the context of steadily improving performance:

Professional - Having great skill or experience in a particular field of activity
Programmer - A person who solves problems for other people

I was able to relate to many of the book's insights - for instance:

Not all programmers qualify as professional, but few can tell the difference
Without professional programmers installations tend to drift into mediocrity
Writing code is not always recognized as a separate skill, talent or profession
In ill-defined situations programmers will define the problem they'd like to solve
Non change is the rule, and change is the exception
The inability to change eventually leads to dramatic or catastrophic change
An average programmer's needs are: belonging, esteem and self-actualization
Some programmers are too eager to code and too reluctant to think
A programmer may prove that a program does what he thinks it should do, but he cannot prove that what he thinks it should do is what the user wants it to do

I especially liked the book's fables. My favorite is The Butterfly and the Buttercup which ends with the following moral:

It's well nigh impossible for those who are motivated by productivity to understand those who are motivated by quality - and vice versa.

There are many amusing sections. For example, Weinberg's Precious Programming Principles. Some that made me chuckle:

Standards aren't standard
An ounce of prevention is worth a pound of cure, but management won't pay a penny for it
Specifications, design and coding can be done at any speed - only debugging takes time

The takeaway for me was the Professional Expiration Test: When learning's finished, you're finished. To that end, I'll continue to read GW's books.

The Critic

2010-01-03T18:57:00.000-08:00

Software developers love to critique software. Combine this fact with my new found ability to look at UI's thru the eyes of Logan, who is four, and the urge to critique is strong!

So...

I use Facebook (yeah, yeah) as a simple/quick way to keep up with "friends." My "user story" would be:

As a friend, I want to quickly scan recent posts so I can see if there is anything of interest that I want to explore further.

Facebook recently created a duel mode UI: "Live Feed" and "News Feed". This just confuses me. I prefer Live Feed but sometimes I'm switched to News Feed. Which mode is active is not obvious because both modes look the same except for a small difference in text sequence, bolding and color at the top of the page. My focus, however, is not at the top of the page, it's on the posts and those look the same.

It's not until I've read a few posts that I recognize them as old, a sign of News Feed. So I switch to Live Feed, and then, OK, now I can use Facebook as I desire. The problem (my problem?) is that the recognition and mode switch detracts from my goal of quickly scanning recent posts.

GOOOOALS

2009-12-31T23:47:00.000-08:00

Welcome to 2010! Let it be a year of professional action and growth.

You've got to set goals if you want to achieve, right? And put them in writing. It's serious stuff. But, I'm not going to get too complex . I'm shooting for doable, understandable, manageable & beneficial.

So, without further ado, here are my goals for 2010:

1. Read a book a month.
Something software development related, either management or technical. Here's my (ever growing) to-be-read list:

Becoming a Technical Leader - Gerald M. Weinberg
Clean Code - Robert C. Martin
Exploring Requirements - Donald C. Gause and Gerald M. Weinberg
Handbook of Walkthroughs, Inspections, and Technical Reviews - Daniel P. Freedman, Gerald M. Weinberg
Pragmatic Thinking and Learning - Andy Hunt
The Psychology of Computer Programming - Gerald M. Weinberg
Software Craftsmanship - Pete McBreen
Understanding the Professional Programmer - Gerald M. Weinberg
Waltzing With Bears - Tom DeMarco, Timothy Lister

2. Finish the exploratory/learning "Rental Management System" (RMS) I've started writing in Java.

3. Learn a new programming language by rewriting the RMS in that new language.
Any suggestions?

4. Write two blog posts a month.
This is harder than it sounds (for me, at least).

5. Take some sort of multi-day software development training.
It can't be all book-learning and coding!

Wish me luck...

Dark Side of the Moon

2009-12-23T20:55:00.001-08:00

There is no dark side of the moon really. Matter of fact it's all dark. -- Pink Floyd

I'm a moon. That is, in the software development community I don't give off any light. I absorb the light from the "suns", the leaders and innovators:

Alan Cooper, Alan Shalloway, Alistair Cockburn, Andy Hunt, Dave Thomas, Gerald Weinberg, James Shore, Kent Beck, Martin Fowler, Robert C. Martin, Robert L. Glass, Scott Bain, Scott W. Ambler, Steve McConnell, Tom DeMarco, Ward Cunningham

There are many others but these are the ones that have had a profound affect on me. My thinking and knowledge have grown immensely due to their contributions. I'm glad I found them.

Can I be someone who contributes to the development community? Someone who has a positive affect on others?

Do I have the passion? It's building. I'm pushing for technical excellence at work. My gut aches when it's lacking.

Do I have a desire to learn? I'm constantly reading books, blogs and articles and my reading list is ever-growing. I'm attending seminars and participating in user groups. I'm testing my ideas and theories in code at home.

Can I lead? I've initiated OO and Agile discussions with coworkers and I've started a coding dojo.

So maybe I'm sparking just a bit?