How to Mess Up Scrum, Part 5

The biggest Scrum failures come from lack of leadership. For one thing, no leadership means no scope discipline.

This is another item in my ongoing series of “How to Mess Up Scrum.” This time, I turn your attention to…

Overcomplicating the Objective

Let me give you an example. A few years ago, I was on a Scrum team that was assigned to develop a “retail portal” for the services this company already sold at old-fashioned store locations. In “phase one” the goal was to put up half a dozen or so static pages, plus one “contact” page to capture basic information so our sales rep can call you soon. That’s all.

It took three developers six months.

How the hell does that happen?

Continue reading “How to Mess Up Scrum, Part 5”

Legacy Code: Wrap a method

I’m a big fan of Michael Feathers’s book Working Effectively With Legacy Code, and now and then I reread it because there’s always something to refresh or remind me.

Right now I’m looking at the “Wrap Method (67)” technique. It’s really simple. I’m just restating it here.
Continue reading “Legacy Code: Wrap a method”

The new C++ standard

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

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.

Conclusion

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

Does anybody still do WinForms? Validation.

So I was hung up last week on a data validation issue in WinForms. It’s a pretty simple desktop application to which I was adding a new Form for maintaining a parent-child-grandchild set of tables. DataGridView is my friend!

One column in the parent table was best represented by a set of radio buttons set to the side of the DataGridView. Turns out, there’s not a super-simple way to bind a radio button group to a column in a DataGridView.

I figured the easiest thing would be to populate the radio buttons from the corresponding column of the DataGridView when the user goes into a record, and to stuff the selected radio button value back into the column when the user moves away from the record. Do-it-yourself binding, pretty much.

Turns out, the Enter event works just great for the former. When I enter a record, the debugger shows the current value of my column in the underlying data source. Yay.

The latter is trickier. I tried using the Leave event, but that’s too late; my current row has already been shifted. I tried using the Validating event, but it didn’t pick up on the changed value of the radio button group either.

A moment with Google gave the answer: radio buttons within group boxes catch the Validating event of the containing box, not the of the whole form. Once I added a Validating event handler to the group box, my radio button values were picked up as current and properly saved.

There’s probably a really good reason for .NET to do this. sigh

Access: Why not?

I don’t suppose Access is ever the only solution to a problem. But in my experience it’s frequently a reasonable one and it spares a lot of drama over acquiring and installing a database engine.

I blogged a few times recently about ways to make Acess databases do kind of what you want when you’re programming with .NET. There was this one about multiple JOIN syntax. Then this one about “parameter” errors. And finally this one about weird column names. Yuck!

Continue reading “Access: Why not?”

The Wire. Down to it.

When you’re up against a sudden deadline, focus on progress towards the objectives–not just bug fixes.

If you’re a big Critical Results fan–and who isn’t?–you may have missed my regular blog updates for the last week and a half. Let me tell you what’s going on.

Continue reading “The Wire. Down to it.”

Programming with Access? Know this about column names

Does your Access database have sketchy column names with weird characters in them? Surround them with bracket characters so SQL will work.

Because it’s the beginning of the week, I’m again presenting more about programming .NET with an Access database.

Last week, I offered help with a confusing syntax error. Before that, I demonstrated the unique way Access handles JOIN. Today I have a tip on addressing poorly named columns in your code. Continue reading “Programming with Access? Know this about column names”

A word about strings and pointers in C++

If you’re inexperienced with traditional C-style null terminated strings, the std::string.c_str() method may yield puzzling results.

This question just came up on Stack Overflow. It reflects a pretty common misunderstanding of how C-style strings are represented by char pointers in both C and C++.

Greatly condensed, it goes:

  • You read some data into a std:string object. You display the contents; it’s all there.
  • You invoke c_str() on that std:string, and display its contents; it’s not all there.

Continue reading “A word about strings and pointers in C++”

At the Old Programmer's Club

Another late night at the Old Programmers’ Club. This time, Tony and The Smartest Guy I Know talk about how Microsoft ruined the static keyword.

Last night I regaled The Smartest Guy I Know, as well as drsweetie’s high school pal Tony, with tales of how Kids These Days Don’t Know Anything and Nobody Does Things Right. It was a scene to warm the bitter soul of any software curmudgeon.

“So there I was,” I began, “optimizing the heck out of an ASP.NET application…” And my audience groaned–although I’m still not sure whether it was because they know how the story simply had to end, or because I was the teller and they couldn’t be sure that it would ever end. Because my stories get to be like that sometimes.

Continue reading “At the Old Programmer's Club”

Lessons Learned

Lessons learned from the last big on-site web development project: figure out what the client really needs, gauge the effort, know who the chump is, and lunch strategically.

Yesterday, I finished up my part of a web development project, working with a team put together by a local software consulting company. Here are a few things I learned or had reinforced:

Figure out what the client really needs

A lot of times I pick up a project that’s a real mess, and the client thinks they need a supercoder to get it all done. I don’t think of myself as a supercoder, and even if I were such a person, the lack of one is usually not the problem. More often, when a software project isn’t going well it’s for reasons like these:

  • redoing the same work
  • poor choice of platform
  • unclear goals
  • not enough time allocated
  • multiple agendas
  • poor controls
  • hoarding
  • wrong kind of discipline
  • reliance on heroics
  • technical “bankruptcy” (when the code gets too complex to maintain)

What do these things have in common? They aren’t solved by supercoders.

You know what though? As I found it, this project had acquired good management and it had a very clear goal. Some of the specific requirements could have been better defined, but there was enough wiggle room that we weren’t really hampered by any vagueness. And our team lead, someone I’d happily worked with in the past, was very capable.

I could have applied some of my amazingly insightful make-your-project-not-suck magic, but no: what this project needed was a supercoder, or two or three. So I did the best I could in that regard.

I’m not talking about the “duct-tape programmer” type that Joel Spolsky lauds in his recent blog post. This website already had enough duct tape! It just would have been extra-awesome if I’d been able to understand the whole code base in a flash, and figure out how all the duct tape worked, rather than having to piece my mental model together one defect at a time.

Gauge the effort

In business terms, a key element for any independent consultant or small contracting firm is knowing how many technical people need to be on the project, and for how long. Nobody wants to be so overbooked they fail to deliver on commitments. Nobody wants unanticipated slack time.

At first, they told me it was a one-month “burst” kind of project. Then, based on burn rate, they scaled it back to three weeks. A bit later the client found more funding to make it five weeks. Then another burn-rate-related adjustment reduced my role to four weeks.

Does that sound awful? Maybe? It’s not. When it’s one of those park-yourself-in-a-cube-and-join-in endeavors, you rarely get that level of communication and adjustment. A lot of clients make it really hard to plan ahead. This one kept adjusting and communicating their time expectations, without being overwhelming about it. Cool.

Know who the chump is

They tell me it’s a truism in poker: There’s one chump at every table; you want to figure out who the chump is. Corollary: if you can’t identify the chump, it’s you.

The blunt truth is that in team software projects there is very often at least one person who hasn’t the skills to contribute much. That’s not always a bad thing: it can be a great opportunity for mentoring via pair programming, code reviews, or simply talking about how code gets done.

I really liked and respected the .NET developers I worked with on this project. On the downside, I couldn’t figure out who the chump was. I made my best effort, but I suspected that my process of understanding the existing code base was just taking too long. At the end, I realized that it took a month to figure out where everything was in this modestly complex system, which is about normal. Still, I hate that feeling: “Am I the chump? Really?”

Lunch strategically

One of the cool things about working at the client’s site is that it puts you in a geographic location that you can leverage. One of my Twitter pals works right upstairs from our war room. Another good friend works afternoons and evenings in the same office park. Our quality lead was a vague acquiantance from a project I did last year when he worked for a different organization.

So I got to optimize my lunch and snack time. I found out about new jobs opening up, in unrelated areas, for which other friends might qualify. I was able to refer my Twitter pal to two industry peers she didn’t already know. I got to hang out with, and get the latest relationship drama from, my office-park neighbor.

Those things wouldn’t have happened had I stayed in my home office or remained virtually connected via coffeehouse WiFi. It was a lot more driving than I like to do, and my car actually suffered, but at least there was that social benefit.

I’m just saying

It was a good engagement. The client is doing a lot better now than before we started, and their confidence will improve even more when the remainder of the team gets cracking on load testing and optimization. Congratulations all around!