a number of articles have shown up recently, discussing the contribution that various languages, techniques and concepts can make to your programming expertise.  However, while I feel that there is merit in each of these ideas, they’ve missed the big one:  ______

______ represents the core of programming, the gist, if you will, of what it means to think about and write meaningful software.  ______ provides you with the right mindset to solve problems, detect errors and, even more importantly, avoid putting errors in your software in the first place.  ______ provides a metaphor for programming that you can use your entire career.

But you don’t have to take my word for it.  There is lots of information out there about ______, and there are a lot of famously smart people who have written about ______.   They’ve had much success, and in fact, often discuss how ______ was critical to their progress as a programmer.  If they were successful using ______, I’m sure you will be too!

Like most things in life, ______ is easy to understand at first, but when you start to get into the details,  you discover that ______ is far, far richer than you had originally thought, and demands a lot more careful scrutiny than you first realized.  Moments to learn, a lifetime to master.   This is the secret of ______ – it is the journey that will give you a lifetime of good habits and strong discipline.

IMO, without a doubt, ______ has contributed heavily to the existing software industry, which, by recent accounting, represents about 7% of our overall economy.  Without ______, I’m certain that software would not be nearly so significant in our lives, and we would all be poorer for it.

Give ______ a try – it is easily available, with lots of support out there, if you know where to look for it.

and I promise you that, some years from now, when you look back at your career, and the successes you have had, you will realize the contribution ______ has made to your prosperity and happiness.

If I said:

“The rise of the warp driveis more than just another speed shift that gets people excited. It will undoubtedly transform the space transportation industry, but it will also profoundly change the way people work and companies operate”

You would almost certainly say “Well, duh, but warp drive doesn’t exist”

And that is my problem with this statement:

“The rise of the cloud is more than just another platform shift that gets geeks excited. It will undoubtedly transform the IT industry, but it will also profoundly change the way people work and companies operate”

—The Economist, “Let it Rise,� 10/23/08  (hat tip: Mike Patrick)

 

I’ve spent the last 6 months getting very familiar with cloud computing, and I struggle with this – not that I think it is wrong, but that I think it is farther away than many think.   Not as far away as warp drives, but still, not something we’re going to see change the industry in the next 2-3 years – maybe 8.   (people generally overestimate what can be done in one year, and underestimate what can be done in 10).  

Right now, CC is a concept looking for a business practice.  Amazon EC2 is nice, but you wouldn’t want to build a typical web busines on it, because your costs would grow linearly with demand, and that’s not where you want to be.   Google Apps are nice, but they seem only modestly easier and cheaper than your basic virtual server hosting package 

(for example, I pay a whopping $5/month for a server with lots of resources for my blogs and Bellygraph)

Cloud Computing has to thread the needle of “wow, I can build a business on that”, and I haven’t see it do that  yet.   I could be blind to evidence, I could be caught up in my outdated web 2.0 dogma, but, on the other hand, I want CC to succeed.  I just haven’t seen the evidence.

 

Here’s the kinds of things that I think would allow CC to take off:

• automatically scaling web applications, at minimal incremental cost – this is CPU, filesystem, memory and database scaling – literally you write your application, and you don’t have to worry about where the data is, or the CPUs or anything – everything parallelizes automatically.
• flash mob insurance – a way to hook in to a CC system to let your website scale automatically when needed, and then dial back down when not.   Again, you need your app to be designed for this.
• Low-cost massively parallel analysis – this is something we can do today with Amazon, but it is cost-prohibitive.  Plus there’s not enough demand out there to build an industry on this
• Minimal latency applications (such as multi-user games) that automatically migrate to be closer to the customers

But I have yet to see the game changer.  I wish I could, because I want to believe

a blast from the past

 

Sample:

The Liar

An entire unit test that passes all of the test cases it has and appears valid, but upon closer inspection it is discovered that it doesn’t really test the intended target at all.

 

 

Looks like somebody’s making a play to be the new Alpha Dog!

 

 

 

Share and enjoy!

As discussed by Uncle Bob

Is it true that an expensive handbag is better quality than a cheap handbag?

Is it true that $150/bottle wine is always superior to $20/bottle wine?

No?

Is a “Ruth’s Chris Steak” clearly better than a Waffle House steak?   Yes?  Then why does Waffle House sell so many more steaks?

 

Software quality is not always a function of price.  Bob provides a number of good points about how to improve quality without increased cost, but there’s the other side of the equation – sometimes people are willing to accept lower quality (steak, for instance) at a lower price.  

If the generally agreed-upon “acceptable level of quality” is unacceptable to you, it’s because you’re a snob.  I should know - I’m one myself.  There are game companies I refuse to buy software from, because their games are buggy and/or hard to use.  I have delayed in buying some productivity software for several releases because I was disappointed with the behavior in the early releases.  That’s income that the software vendor did not get, because of the poor quality of their software.

There’s an equilibrium there – if the quality of software drops enough, people will vote with their feet, and choose the software that has higher quality.  Even if it is more expensive.   There’s nothing magic about software – it’s a product just like any other, even if the quality is hard to see.   It is there, and at the right place and time, it will be important.

But just because the generally accepted level of quality is lower than you would like does not mean that software will inevitably be crappy.  You should just expect to pay for that extra quality. 

And if your answer is “I shouldn’t have to pay extra for quality”, I suggest that you go to Ruth’s Chris and demand a Filet Mignon for $4 and see how far that gets you.

I guess this means I fall into the “quality isn’t free, but it is a product differentiator” category.

 

 

 

 

 

 

Interesting counter-take on Agile development with a hero-programmer model.

This is just one example, but it would be interesting see if other examples support or counter this experiment.  

My previous experience suggests that the less complexity you send overseas, the better you are.  which means that you need people locally who can control the complexity and come to (relatively) fast agreement on complexity-containment strategies and tactics.

 

 

 

Mark Levison has some good advice for those Agilists who find themselves out of work.   My only quibble is with item #1:

Get an email address with your own domain name. Having hotmail/yahoo/gmail address just looks unprofessional. Domain names are cheap and you can alias your domain to a google apps or any other acct. It just looks better.

I agree that yahoo, hotmail, aol, etc look unprofessional.  However, gmail, IMO, is not in the same boat.  And I say this as someone who has many “vanity plates” – undefined.com, bellygraph.com, picobusiness.com, statusme.com, enterpriserails.com, indefinitearticles.com, agilefaq.com  (actually, that last one would be great to build up if I were unemployed).   

Speaking only for myself, I find it much harder to keep track of an email address if the domain name is long and/or uses dashes.  It’s so much easier to say “gmail”.   Your mileage may vary.

 

Elegant Code asks “What’s the next big shift,the one you’ll never see coming”

I think that’s a fairly easy question to answer – its the technology that I’m skeptical of – that doesn’t seem like it will ever really work in my lifetime.  For me, that’s one of the following (ranked from least skeptical to most skeptical):

• truly arbitrary/scalable cloud computing
• generalized AI
• silver bullets
• semantic webs
• frameworks that actually allow non-programmers to build complex apps
• DMCA-compliant software

 

 

I’ve been unable to access Indefinite Articles from the web interface for about half-a-year now.  I thought it was a HTTP Redirect issue, and tried a few times to resolve it, with no luck.   It wasn’t the end of the world, because I could post via MarsEdit, so I just did that, and more or less ignored the problem.

A few minutes ago, I told cPanel to repair the database, and voila, here we are.  And I’m betting that comments will work again now.

This isn’t the most exciting tutorial for Behavior Driven Developmentonline casino net (it talks more about the techniques than the theory), but if you want to learn more, it’s worth a look.

• Creating immutable objects in Groovy – they made this surprisingly potent.
• The object-builder pattern – to help you during the setup of complicated unit tests.
• Agile – Beyond Best Practices – A mild rant against some of the recent buzzwords.
• Different perspectives on the value of unit testing – a very useful read about some of the anti-unit-testing backlash, where it comes from and some of the good points.
• Coding principles instead of rules – thoughts from Jeff Atwood

Any methodology or process, even an agile one, does not protect you against making bad decisions. If your company runs out of money, it will not matter how beautifully structured the code is. This is just as true of waterfall projects as it is of agile ones.

TDD is hard. It is also really, really valuable.

My friend Mark Levison provides ideas and advice on overcoming objections and dealing with the technical and organizational challenges associated with TDD.

Understand objections. They exist for a reason. Understand the reasons, and find solutions to those issues. Dismiss the reasons, and you will not gain traction, you’ll gain obstacles.

Jay Flowers has the goods.

This article starts off with an amusing anecdote about over-engineering, and then provides a bunch of insights into the usefulness of Apache Tomcat as a low-cost, lightweight servlet engine for your J2EE apps. Then he talks about something he wrote to help maintain Tomcat servers.

Anyways, if you’re looking to simplify your web stack, consider Tomcat. It rocks, and it’s free.

See here for the start of this series.

Imagine you have a small number of customers, possibly one. And, you have essentially zero competition. That is to say, not only do you not have other organizations offering competitive products, your customers don’t really have effective alternatives other than to work with you.

Even better is if your customer(s) have an incredibly long planning window – years or more.

In that kind of environment, what would agile buy you? There’s no need to respond quickly to changes in the market, because there essentially is no market. There’s no need to move fast, because you have nothing to compare yourself to. There’s no need to risk pissing off the customer with a half-finished project – you’re already at the top, there’s nowhere to go but down.

If I were in charge of such a project, I would potentially find value in pair programming (although I would probably already have a very disciplined review process). But I would absolutely allocate tremendous amounts of time to pre-planning, and getting everything “just so” before writing a single line of code (other than tests and prototypes of new technologies, etc).

Heck, if I worked at a place with essentially no competition, I’d probably look at agile and think ‘what a bunch of reckless speedsters’ I would probably find the whole concept of “keeping up with the competition” both uncomfortable and sub-optimal.

And it would be… if I had no competitors.

Glen Alleman has an interesting post, where he devalues Unit Testing, in favor of testing requirements.

I wonder what he thinks of Behavior Driven Development tools, such as EasyB. Those would seem to be a closer fit to what he’s looking for.

These aren’t earth-shattering insights, but it’s nice to have some reminders of how to make the whole bug tracking process a little easier for everyone involved.