Feeds:
Posts
Comments

Have you ever received an email, sent to a list, where the sender put everyone in the to: or cc: field of the email?

This has happened to me several times over the past few weeks.  As someone who has spent several years in the email marketing business, I’m always a bit curious (and irritated) and I often peek under the covers to view the list of subscribers.

Last year I received a broadcast email from CCAP, the state agency that sells the data (a SOAP interface) we use for ForeclosureAlarm.com. The email included all their other customers in the “to:” field.  It was very interesting to see a list of other companies that purchase that data.  Very interesting.

Don’t get me wrong, I don’t take this lightly.  I get a little upset when this happens.  Not this upset,

but I’m not a happy camper that my email address has been shared with hundreds of people I don’t know. Sometimes I’ll even reply back to the sender letting them know about this magical thing called a bcc.

This gets me to the google and their gmail service.  You see, gmail already does some fancy things with their service.  For example, if you say something in the email about an attachment, but you don’t actually attach a file, they tell you.  Pretty slick and a very nice feature to keep people from embarrassment.

Gmail should be checking emails that include a bunch (dozens or more?) addresses in the cc: or to: fields and then provide a friendly note to the sender, with maybe a link to a knowledge base article, that maybe the sender wants to actually put all those addresses in the bcc: field and why. It would help protect their customers from abusing their friends email address and it would make gmail better.  A win win.

There you go Google, keep track of improper use of the “to:” field by your users and it’ll help keep me from feeling like this.

Many articles have been written on the benefits of pair programming.  Often, (including the wikipedia article) the focus is on the typing aspect of programming – the speed at which code is created as well as the real time review of what is typed.  I believe this is one of the least important aspects of pair programming.

Programming is more about Design than Typing

Over the years I’ve noticed a difference between great programmers and average ones.

Average programmers are often seen typing.

Great programmers are often seen staring at code.

The reason, it seems, is because great programmers are thinking bigger.  They’re thinking about dryness, code consolidation, reuse, simplicity, using the existing framework, and a lot of other things than the specific tracker task they’ve been assigned.  Average programmers focus more on simply creating the code and tests for that task.  As a percentage of their work, average programmers type more.

Thus, focusing on the typing aspect of programming is biased toward the mediocre. It is the “small lever” within software development.  The big lever, the one that effects the long term cost of software development and maintenance is design.  And design comes from thinking.

Design (and thinking) is improved by dialogue

The real power of pair programming comes about due to the dialogue between the developers.  In order to present a design idea, the developer needs to put his/her idea into words and that process alone is often very valuable.  It is very easy to have an idea about how to solve something, yet gloss over some of the details or complex issues.  By taking a vague design thought and putting it into words, the person with the idea is actually learning about his/her idea. Obviously,  this process of verbalizing a design is usually missing when working solo and often a developer will simply head out in a “direction” confident they will figure out the details as they proceed.  With pair programming, a pair usually doesn’t allow this.

This verbalizing is inherently a good thought process.  The gaps in your thinking are exposed.

Along with discussing the solution design, the developer also likely will state their assumptions about why they think something should be done.  The assumptions could be about risks, costs, testability, etc.  And again, that dialogue between developers leads to further knowledge transfer and understanding.

Here’s a quote from The Costs and Benefits of Pair Programming

We often came up with different ideas about how the design should go and the result of arguing over which one was better often led to a truly superior hybrid design.

One last note about design.  I have found that pair programming tends to keep developers near the minimum of the cost curve (written about in Line Count and Maintenance Cost) instead of the arcane and wordy areas of the graph.

To sum it up, forget about all the nitpicky stuff in pair programming, that is not the long lever. It’s about quality and maintainability of software, but that will only happen if the developers are truly pair programming and not simply sitting together at the same keyboard.  But that’s a different post.

Lean != Agile

Lately I’ve been reading a lot of software development articles which use the words Lean and Agile as if they’re synonyms.

They aren’t.

I’ve been implementing both lean and agile processes since the early 90′s.  The concepts aren’t new, but they are relatively new to the software development world.  I’ve read about and taught TPS, SMED, and many other parts of lean production as well as many of the concepts used in agile manufacturing.  Their application to software is incredibly similar.

Lean is an inward focus.

Lean is a measure of the entity separate from its customers and historically is a measurement of waste.  Reduce waste and you are more lean.  The Toyota Production System (one of the oldest lean manufacturing system) has a constant focus on the elimination of waste.

Lean is loved by many executives because it conforms to the “world as machine” view. Taylorism, and it’s descendants such as business process re-engineering, have viewed the business entity and its processes (and the larger scale systems the organization exists within) from a mindset of planning and control – again, a world view most managers seem to prefer.

Agile is an outward focus.

Agile is dirty, organic, unknowable, unplannable, which makes managers and executives uncomfortable.

To be Agile, you do need to be somewhat lean, but the leanness is FOR agility, not the goal.  The difference is important.

Agile is measured not with internal measurements, but as a measure of how well the entity responds to changes in the external environment.  Waste and leanness are not the goal and as Eli Goldrat has shown time and time again, being more lean in the wrong places can make you much, much less agile.

It’s important to understand why agility has become so important over the last several decades.  It’s due to the continual shortening of product life cycles, customer order cycles, and the increase of product competition due to information exchange.  No longer can you release a product once every few years.  Even the idea of software versions is becoming somewhat obsolete (what “version” is the google search engine?).

Which to focus on?

I spend most of my time in the web world where agility, the ability to adapt to a changing competitive landscape, is the number one competitive advantage for a software firm.

Agility is customer focused and these days the customer is king.

So I choose agility over leanness every day.  It isn’t even close.

We all know that the less lines of code (SLOC), the lower the maintenance cost, right?  Not quite.  As with most things in this world, there exist marginal returns in the pursuit of brevity.

Over the past few years I’ve been working a lot more with Ruby and the Rails framework.  I’m not sure why, but there seems to be a social norm in the community of impressing others by consolidating code to as few lines as possible (often just one) with the (mistaken) belief that the code is better.  And that sometimes makes me feel like this.

Those programmers that create some of this amazing, yet arcane code are usually some of the best programmers I’ve ever worked with.

The problem is that they’re often misguided in this pursuit of brevity.

The relationship is probably not linear and there is likely not only diminishing marginal returns (which are almost always inescapable), but there is likely a negative relationship at some point.  The reason is that although the advanced programmer can handle the complexity of the “arcane” lines of code, those that maintain code are often not the ones writing it – specifically and also in skill level.  The more arcane the code is, the more time it will take those maintaining the code to understand it.

The relationship is probably like this graph.

It’s been my experience that good programmers do not need to be reminded of writing DRY and concise code.  Quite the opposite.  As a project manager, I believe it is necessary to inform and remind those great programmers of the potential for increasing costs due to an overemphasis on the reduction of lines of code.  Strange but true.

When I worked for the State of Wisconsin (as a contractor), I had many great conversations with Mark and Jon about agile software development.

One day I wrote down a list of 25 thoughts on risk management and testing.  Eventually I’ll weave these ideas into articles, but for now, just a <ul>

* Everyone contributes risks

* No risk exists without probability and impact

* No impact is infinite

* All impacts are measurable

* Risks drive level of design

Continue Reading »

Please banish the use of the word “Requirements” from your software development lexicon.  Immediately.

For many software teams the requirements document is the king of documents.

You know the routine. The software team works with the customer (or customer proxy) to put together a “complete” list of “requirements”. Once that is done, the team writes the software implementing the requirements and voila! the project is done.

Or maybe not.

Continue Reading »

It isn’t just Ruby on Rails login forms that are broken. The majority of login forms on the internet are fundamentally broken.

In what appears to be some form of risk management strategy, these login forms introduce a different risk to the websites that use the default behaviors – in RoR sites, this is often either AuthLogic or RestfulAuthentication.

Both are broken in a big way.

Continue Reading »

The other day I subscribed to a daily newsletter from a new “social media” website. This is a NEW website – they have just become beta. They’re not big, they’re a small startup.

I tried to reply to one of the emails they send each day. And I quickly discovered they send these using a no-reply address. Meaning I COULDN’T reply.

And that broke my brain. This is a company which is all about web 2.0 and the new communication mechanisms available. Yet they have broken the single most used communication process of the internet!!! Why would they do this? People have been sending and replying to emails for decades now. Decades. And it works.

Continue Reading »

Almost on queue, Twitter has recently done (twice!) what I’ve been thinking about lately.  They have removed features.

Removing features is very tricky and fraught with problems, even if those features are used by very few people.

Continue Reading »

So the twitter changed their notification emails for when someone follows you. And they are definitely an improvement over the old notifications.

But they are broken.

I’ve read several articles talking about the “richer, HTML version” of the email. Richer? What year is it?  Formatting doesn’t make something “rich”, data does.

Data is rich, markup is lame.

Continue Reading »

Older Posts »