The new C++ standard

I spotted on Esther Schindler’s Twitter feed a link to the Dr. Dobb’s article on the new C++ 14 standard.

This is exciting for me. I really like C++, even though I hardly ever get to use it. It’s a super-sharp power tool that simply isn’t as useful as C# in the database-heavy applications I usually work on. I have a lot of nostalgia wrapped up in C++. I remember running across the Stroustrup book in the public library (of all places!) and being fascinated by the concept and implementation of object orientation.

Sure, a lot of people would say that ruined me, because C++ is far from a purist’s language, but in its era C++ offered a pragmatic solution to a great many typical development challenges.

What’s new in C++

First of all, you know how you can use that var declaration in C# when it was too inconvenient (or at times impossible) to specify the type of a variable? You can do that in C++ 14 and you can specify the return type of a method the same way!

There’s a new [[deprecated]] attribute. It doesn’t break any code, it just kicks out a warning when you try to call anything that you’ve flagged as deprecated. Good way to soften the transition away from an API or implementation.

Syntactic sugar: You can now have digit separators in constants. You can write a million now as 1,000,000 if you want.

Generic lambdas with auto type parameters! That’s kind of esoteric, but the point is being able to declare lambdas that will figure out for themselves at compile time what argument types they need. It makes them more reusable.


C++ is still vital. It’s changing and getting better. I like it. I wish I could use it more.

Make your standups not suck

In the past five to eight years, as I’ve worked in a lot of big corporations that have “gone agile,” I’ve been in hundreds of daily standup meetings. Many of them have been great. Many more have completely sucked.

Let me talk about the suckage and how to deal with it.

First, fundamentally: actually standing up

First thing, if your standups are honestly too long for people to be standing up comfortably, they are too long. “Standup” isn’t just a cute name. The idea really is to make it super fast and get back to work.

Maybe I’m a little biased in this because of this worn cartilage in my left knee that gets rough when I stand still for too long.

How to deal with standups that run more than about ten minutes:

  • Consider a smaller team. Maybe five to seven “pigs” is best.
  • Quiet the chickens. If you’re observing as a stakeholder, great! But this is not your meeting. Just listen.
  • Stick to three questions. Everything, and I mean everything, comes back to the three questions.
    • What did you get done yesterday?
    • What are you trying to get done before tomorrow?
    • What are your obstacles?

Second: keep it on track

A pattern I keep seeing is when the team lead, or more often that person’s manager, has decided that someone’s work isn’t up to par and uses the standup as a way to focus pressure on that person. That’s bad management style in its own right but it also makes the meeting itself less useful. If you use the gathering to point out how many defects one team member is generating, everyone else will minimize their defects to avoid being similarly called out. If you bust one team member for overshooting an estimate, the rest of team will tend to pad their estimates. And so on.

To eliminate this particular kind of suckage, make sure you’re talking about today’s work today. That’s all the standup is for. Discipline, correction, motivation, and evaluation are not on the agenda. It is for planning one day’s work. You want another meeting, make another meeting. Don’t impose on this one.

Finally: the team owns the sprint

Whether or not you’re organized as an actual Scrum team, team ownership is always a good idea. If something’s not going well, the individual team members are almost always aware of that first. If you’re doing it right, they have already started to make adjustments even without the formal intervention of a standup meeting. When that’s the case, and it usually is, less management is probably better.

If you find yourself dictating solutions, you’re undermining the team’s ability to solve its own problems. Resist the impulse. Step back. Give the team at least a couple of standup cycles (which means two or three work days) to figure it out before you consider imposing a plan. At worst, the time “wasted” this way will pay off in education and experience.


Again citing the Agile Principles: Give them the environment and support they need, and trust them to get the job done. More support, less intervention, fewer distractions. That’s how to make your standups not suck.


Preparing for GiveCamp 2011

Hey, everyone… I’ve been out of the blogging space for a while for a lot of reasons. Some of it has to do with having too many projects going on at once, with competing deadlines. Some of it’s about being tired. Some is because the things I want to write simply aren’t ready to hatch yet. And a little of it comes from this project I’m not supposed to say a lot about.

But here’s something new! At the end of the day yesterday I spent some time in conference with the organizing team for this year’s Cleveland GiveCamp. We already have bunches of eager volunteers, a floating venue, some early sponsorship interest, and a decently clear idea of what’s going to happen next.

What you need to know

GiveCamp is a bunch of designers, admins, software developers, and business people who pitch in for a weekend to create websites and software applications for free for nonprofit organizations.

This year in Cleveland it’s the last weekend in July, starting the evening of Friday the 29th and rolling through the afternoon of the 31st.

We haven’t decided which agencies and organizations are going to get new websites and software applications this year, but we will probably start accepting applications around May 1st.

We are already taking volunteer commitments! If you can design web graphics, or can lead a project, or know something about content management systems (especially WordPress), or write software, or are good at organizing, or if you just want to help–please sign up now!

We are also working on a sponsor packet, for companies and individuals who might consider donating money, materials, food, T-shirts, or services. That should be available within a couple of weeks. GiveCamp runs cheaply, but we still need a lot of food, caffeine, and supplies to keep it going all weekend.

Last year

Cleveland GiveCamp was a huge hit. We used all of the LeanDog boat plus half of Burke Lakefront Airport (thanks everyone!), had about 110 volunteers who worked on 21 projects, and left charged up to do even more this year! I personally know three people who got hooked up with new jobs as a result of the connections they made at GiveCamp, and everyone had fun. Also, the food was far better than at most tech conferences.


If you’re going to be anywhere near Cleveland at the end of July, here’s what you can do:

  • Volunteer for the big GiveCamp weekend of July 29-31.
  • Start planting some mental seeds for sponsorship at the places where you eat out, work, or shop.
  • Talk to your friends and associates in nonprofit organizations–do their current websites suck? Are they looking for some kind of new software program that doesn’t already exist?
  • Watch this space, and, for more in coming months!
  • Are you in for this year? Were you there last year? Drop a comment and tell us how it went.

I promise hard work, nice people, and lots of fun. See you in July!

What I like about Rails

Somebody asked a few months ago on LinkedIn, “What do you think about building a web application in Ruby on Rails?” Here’s my short answer:

Specifically, I love the way Rails lets you do database access. The simplest way to hit a database table with Rails is to run a generate scaffold command that creates the table for you and writes all the code for a super-basic CRUD (create, update, delete) web application. You can edit the generated “scaffold” to make it prettier or to add functionality.

When you go just a little farther, you find that the ActiveRecord class does most of the boring database work for you. Every table (“Model” in MVC parlance) is set up to inherit from ActiveRecord, and you don’t have to write out (in your code) what columns it contains because ActiveRecord figures it out for you at runtime.

Better still, you can add lines to your Model code such as :has_many x or :belongs_to y to indicate relationships (joins) with other tables. Again, Rails works out the details. You really don’t even have to know what database software is being used; ActiveRecord takes care of the vendor-specific differences.

Those are some specific things that make Rails so nice for web and database development. One of the hardest things for some people is getting used to NOT writing so much repetitive code.

That’s at the top of my list. What do you love about Ruby and Rails? Comments are open.

What’s on your mind?

I’ve been working on so many offers and new ideas that the blogging hasn’t quite kept up. So right now, the floor (and comment section) is yours. What are your thoughts on software development, Agile practices, and Projects That Suck™? Anything I haven’t covered? Technical or process questions?

It’s time for a conversation. Who’s in?

As a possible starter… affirm, deny, or qualify the following statement: “The cost of adopting Agile development methods is primarily not paid in cash out of pocket.” What do you think?

Jazzed about products and projects

It’s Friday, which is usually my day for the big-picture, deep-thinking, philosophically confusing kind of blog post. This time, however, I’m going totally commercial.

I’m excited about this!

A couple of very different items that I’ve been working on for a long time have finally reached a state of substantial completion. I’m ready to get them into a market-friendly state that will enable me to help more people, in a very sustainable way that everyone can afford.

The first thing

The first thing is a Windows application that was custom-made for a local nonprofit organization. They’ve implemented a very successful environmental health program (one of many) that works with families to identify home health and safety hazards, remediate those hazards in a cost-effective manner, and educate the family on ways to maintain the healthy state of the home. There’s a lot of “workflow” involved, and the reporting issues are fairly intense because of federal grant requirements, and it’s further complicated by the need to support an offline distributed database because the inspector with his Tablet PC doesn’t have remote access in the field.

The new application has been in a solidly usable beta state for about six months. Now we’re calling 1.0 done!

[main dialog for Healthy Homes application]
The main screen looks kind of like this.

The next step

So consider this a pre-release announcement. If you’re working with HUD Healthy Homes or any similar program, and manual recordkeeping is making your quarterly reports a nightmare, or if you just want a better way to schedule all those inspections and followups… we should totally talk. Get in touch with me now and we can arrange a preview.

The other thing

The other thing, which I’ve been talking about on Twitter a lot recently, is my new Startup Booster series for entrepreneurs whose software projects do not yet suck, but might! If you’re starting a company, and particularly if it’s not a software company, the last thing you want is a software project that costs too much, takes forever, and doesn’t solve the problem you had in the first place.

Isn’t it hard enough to get your idea off the ground? The software part of your strategic plan has to help, not get in the way. That’s why I’m building the Startup Booster. It’s a series of super-accessible information products that show you a really clear path to making stuff work even if you aren’t a software person yourself.

Right now, I’m putting the finishing touches on the first module, Buy or Build? It addresses the first and most important question that a lot of entrepreneurs miss: “Do I need to do a software project at all?” In it, I show you a really simple and thorough eight-step process (with a flowchart!) to help you decide whether to buy an existing package, get set to develop something custom, or skip the whole thing.

That’s the perfect implementation of my favorite rule of thumb: the only bug-free program is the one you don’t have to create to begin with.

Here’s what you get

The first module, Buy or Build? delivers a PDF and an MP3. The PDF includes an overview of the whole process, the aforementioned flowchart, and a super-simple workbook that you can write in as you go along. The MP3 is half an hour of my soothing voice, giving you background on the buy/build decision and explaining all the steps with real examples and a few bigger insights.

Here’s when you get it

At this moment, Buy or Build? is in preview. You can buy it at a special discount price of $17 if you’re on my free keep-in-touch eZine list. Otherwise, you have to wait until next Wednesday to join in the fun.

Of course if you now buy the preview, which is honestly kind of rough around the edges, you’ll get the tidied-up finished version for free next Wednesday. Like duh.

The rest of the series

But wait! There’s more! Future Startup Booster installments will help with topics like these. (Not all will be separate modules though.)

  • Can you do the software project yourself? Is that so crazy?
  • Figuring out what kind of help you need… how to get it… how to manage it… and when to fire people.
  • Is Open Source or Free Software right for you?
  • Deciding on a platform (e.g. Mac OS X, Windows, Web) and tool set.
  • How to know when your contractor is snowing you.
  • Protocols for problem-solving.
  • Measuring return on investment.
  • Can you turn your project investment into a profitable product of its own?
  • When to upgrade.

I haven’t worked out all the pricing, but each module will be pretty similar to the first in terms of content and bulk: a half hour of audio, a workbook, an overview, and a visual aid. There will be a really good no-regrets bundle price if you decide to get the whole series. (By “no regrets” I mean the bundle price is discounted by what you’ve already paid for individual modules, so you won’t have to go “Dang! I should have waited for the bundle!”)

Next up:

I’ve already started on the installment that addresses getting help with your custom software project. I’m hoping to get that preview out to friends as early as next Monday and releasing it to the public in mid-February. This is an ongoing process, with new content at least every month or so.

So there you go.

You can get on the keep-in-touch list right now and order the preview of Buy or Build? at a pretty cheap price with the free update, or you can hang around until Wednesday and pay a bit more for the flowered-up product.

Up to you though. I really hope you decide to check this stuff out, because if you’re trying to get a startup going this stuff can really cut out a lot of the cost, hassle, and stress of software projects gone bad–and so much more affordably than figuring it out with a consultant!