mark.w.schumann

About mark.w.schumann

Posts by :

, , 0 comments , ,

Don't have coding standards

I’m doing a new thing now!

If you’re currently on my eZine and announcements opt-in list–and you should be, because it’s usually not boring–you found out about it this morning.

Long story short, and not to kill the suspense, the main thing is that if you send me some problematic C# code, along with a very reasonable amount of money, I will turn around a solid code review, complete with prose narrative, suggestions, and maybe even bug fixes. (I’ll put all the details up next week, but that’s next week’s problem. You should be on the opt-in list!)

One thing I won’t do, though, is impose “coding standards.” I don’t think you should have them.

Why you shouldn’t have “coding standards”

Okay, that’s actually wrong. I do think you should have coding standards, even if you work by yourself as a lot of my fans do. Have a regular, standardized way of naming things. Of indenting. Of when to break something into more than one class. Of when to unroll loops.

Sure. There’s nothing wrong with that if it makes you feel better.

The benefit of having standards is that you don’t have to think about them. That’s why I’m saying… don’t have them.

Here’s what I really mean.

Again I’m going to play the “I’ve worked in sixty development shops” card. I’ve seen a lot of single developers, startups, growing concerns, flailing concerns, and mega-corporations do software development to a WIDE range of success. And pretty much always, someone senior at some point calls a meeting and says…

…Let’s Have Standards.

In practice, that means you spend a few hours in more meetings going over the oh-so-important issue of whether to name your classes in camelCase or PascalCase. Where the curly brackets go. You know, all that stuff that ReSharper already does for you.

I’m saying those meetings are not a productive use of time. Your deliverable becomes a set of rules that everyone either has to try hard to remember, or rules that nobody bothers to follow at all. And I keep asking, what is the problem you are trying to solve here? Nobody’s totally clear on that.

  • If your architecture is too complicated, reduce the architecture.
  • If you lack unit tests, build code with unit tests.
  • If your code is too tightly coupled, think about where the seams should go.
  • If it’s hard to find the class you want, pick better class names.
  • If you have a lot of duplicated code, refactor it to remove the duplication.
  • If your problem is excessive defects, then “standards” aren’t going to help at all.

So either you think about these rules and they get in your way, or you don’t follow them and they don’t help you. In any event, they don’t solve any actual known problem. Come on, when was the last time you honestly couldn’t get something to work because the curly braces were in the wrong place? Ever?

Here. Let’s make it easy.

Why not save everyone some time and annoyance and just use ReSharper? You can leave the default ruleset, which is a pretty reasonable one, or customize it if you really really want to, but the important thing is to set it up and not worry about ever again.

The main thing is to know what the problem is that you are trying to solve instead of getting excited about a solution that may not help you at all.

I’ve found that the shops that take more than about fifteen minutes, ever, to discuss “coding standards” are the ones with pretty severe process issues that “standards” won’t at all fix. The right path is directly to the source of those problems, not one of avoidance.

 

, , 0 comments , ,

Change observation, not change control

A while ago I posted about Baqbeat, an enterprise systems management tool being developed by my college homie Dave. A lot of things have changed since then.

For one thing, the name has been updated to the less quirky but more descriptive “Congruence.” For another thing, the code is actually getting done. And, as we were discussing the other day, the minimum usable product concept has been pretty well refined.

Why this thing even matters

In a recent Facebook chat, Dave put it this way:

That is my real, underlying motivation… cutting back on the bickering and finger-pointing! It starts with replacing “But we didn’t change anything!” with “What changed when?” and getting a computed rather than human answer.

Then I ran into John, who runs a pretty substantial outsourced data center, at my favorite coffee joint in Lakewood and talked his ear off for an hour and a half. The thing he picked up on was the distinction between change control, which everyone wants to do but nobody has figured out, and change observation, which is actually feasible. I think it was John who said that trying impose a global solution to maintain all the database structures, configuration files, source code releases, and other knicknacks in your big corporate setting is “boiling the ocean.” He’s right. Strategically, you can try to control everything–which becomes a huge top-down endeavor that depends on someone making a big decision and making scores of underlings follow through–or you can take the gentler approach of watching what does change, and correlating it when something goes wrong.

I could go on for a while about the Congruence architecture that supports all this monitoring and correlation, but the cool part for me is that it has Agents and Minions and Dave doesn’t know very much about .NET. So in a couple months you may see me coding a base Congruence Agent for .NET.

For another perspective, Dave summarized his “aha! moment” on this point about observation.

What you can (and should) do now

If you have anything to do with changing or managing stuff in a network that has more than about three computers, go to the pretty placeholder site for Congruence right now and get yourself on the email notification list.

Start thinking about things in your network that change and break stuff. Think about how much it will help to have something that just lets you know what changed.

Get ready for a fall pre-beta thing.

 

0 comments

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.

Summary

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.

 

, , 0 comments ,

It's a buzzword if you make it one

I saw this on LinkedIn a few years ago:

The bulk of my professional career has been spent working on software solutions for start-up companies. These projects typically (1) do not have established coding practices, (2) have tight timelines, and (3) have requirements that can change on a day-to-day basis.

With this in mind, I am always interested in learning about more effective approaches to software development. So my question is: “Is agile development yet another buzzword, or is there substance to this approach?”

Here’s how I responded:

Think about Agile as a means to get solid, well-tested software that is designed well, solves problems, and is amenable to change. You don’t need to have every coding standard determined up front–perhaps you’ll want to use an Agile process and mindset just to develop those standards–but your efforts will definitely fail if you think of Agile as a mess of shortcuts.

If it’s slapdash, it ain’t Agile. If it’s a shortcut, it ain’t Agile. Agile probably feels like the long way, actually, because you have to pay more attention as you go along.

Agile usually means less design up front in exchange for continuous design as the project evolves. The exchange part is important: there’s still no free lunch. But it’s not design-design-design-code-code-code. It’s design, code, design, code, design, code. (Or better still, it’s design, test, code, design, test, code…)

Your item #3 in particular (daily requirements changes) could point to managerial dysfunction, which makes Agile really hard; or it could point to a dynamic business model, which makes Agile incredibly useful. Or both. You may well find that a well-executed Agile development process draws attention to poor executive management. (Whoops.)

In answer to your question, though, Agility is definitely real. What’s not real is the idea that you can sprinkle Agile fairy dust on a hierarchical mess and everything is all better.

In fact, about the worst thing you can do is to impose Agile practices (such as daily standups, user stories, and sprints) without working the cultural changes that motivate them. For example, I’ve seen the daily standup used as a manager’s checkin and problem-solving session. That’s not a bad thing to do, but it’s not Agile because it makes one person the bottleneck, and it almost always becomes a scorecard situation rather a collaboration.

Likewise, the essence of the sprint (in Scrum) is that you use each one’s retrospective to inform the plans for the next one. The idea is to get rapid feedback from everyone and actually adjust to it. Which explained why I laffed out loud when overhearing a neighboring team’s project manager crow that “We’re really Agile! We have all our sprints planned for the next two years!” Sure, she got her Gantt chart filled out, but she precluded all meaningful input from the team.

Long story short: it’s real. But the key is to forget about the Agile practices and “tricks” you want to learn. Stop, pay attention to what your team is (overtly or covertly) asking for, and go about changing things in response to how your team really works. There are no buzzwords or shortcuts to it. You have to be willing to listen, to give up power, and in many cases to find out you are totally wrong.

If you’re up to that? Then it’s not a buzzword. But that’s up to you.

, 0 comments , ,

Things you can't possibly know

My attention was drawn this morning to an article on “10 Technology Skills That Will No Longer Help You Get A Job.” I’m not so impressed, mainly because I spend a lot of time around people who do research. This… isn’t research.

#3, “Software Support,” has no support.

The evidence for #4, “SEO Specialist,” is that Google renamed its Search Group. Nomenclature has power! That’s why my retirement account is named “Piña Coladas on the Beach With Jodie Foster.” (I am not making this up.) It should work, right?

#5, “QA Specialists and Managers,” seriously? “These days, the tech industry seems to be following Google’s lead and turning everyone into beta testers.” Hey, just because it is being done doesn’t mean it really can be done. This is a trend that won’t work out. (As some of the commenters pointed out, how’s that going for military and medical applications?)

I could go on, but the main thing I’m seeing in this article is a host of extrapolations, half-baked wishes, and flip assumptions. I do that all the time, too, but I save it for when I’m bored on long driving trips with anarchists. Heck, even my speculative blog posts here are full of anecdotes, not wild guesses.

Honestly, I’m just not seeing the value-add in that article. Maybe it would have been a good “link collection roundup” kind of post. Nothing wrong with that.

, 1 comment , , , , ,

Is it worth it?

I got a kick out of today’s XKCD comic strip. (Chart: “How long can you work on making a routine task more efficient before you’re spending more time than you save?”) It reminds me a lot of a conversation I had last Friday with an entrepreneur who’s trying to automate some, but not all! of his information business.

See, “Allan” gets a lot of documents that are not so well standardized, puts their contents into a database, and essentially gets paid by his client companies to let them know when and where they–or their subsidiaries–are mentioned. (There’s more to it than that, but this is the relevant part right now.)

More

, , 3 comments , , , ,

"Minimum Viable Product" jive

My college homie Dave is working on the “Minimum Viable Product” (MVP) version of his Baqbeat product. I’m always interested in what old friends are doing, so I asked him about it.

Baqbeat is a little hard to describe. Dave filled me in:

Baqbeat generates timelines of configuration changes to all the servers in
your development and operations environments – version control, build
servers, app servers, databases, and others. It automatically infers
related events on different timelines. So for example, you can see problems
in your production environment and immediately trace it to the code change
that broke it.

More

, 0 comments , , ,

Help right now for tech-dependent startups!

(tl;dr: Answer a few easy questions to see if I can help your startup!)

Do you have a startup company that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Are you still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?

I’m hearing you.

So you have this small business. You probably just started it. You’ve got a pretty good business plan, you’ve stashed some money to keep it going until it breaks even and can pay you, you’ve worked out health insurance and stuff… or maybe you’re keeping your day job and working a lot of nights and weekends to get it together. And it’s a cool idea: some product or service that people are definitely going to want to pay money for. It’s exciting and terrifying, because you don’t know what could go wrong, but you’re also a little apprehensive about how it will go right in the end.

More

, , 0 comments , ,

Pre-Announcement: Help for your tech startup!

Well! I just spent a lot of time with various tech-related startup companies. Some of them have Projects That Suck; others are simply getting started with new things. I’ve learned a lot more about what does and doesn’t work, and I’m ready to share the results with you.

Do you have a startup that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?

If this sounds like you, watch here next Wednesday for the plan and the details. We can work together to get your startup project on track, within budget, and under control. I’m really excited about this. I think you will be too.

Page 3 of 11
1 2 3 4 5 … 11
‹ 1 2 3 4 5 ›»