Stories about Software


BDD in .NET for Complete Initiates

Editorial Note: I originally wrote this post for the Infragistics blog.  You can check out the original here at their site.  Go on over there for content from me and a bunch of other authors as well.

It’s pretty likely that you’ve heard of behavior-driven development, or BDD.  Maybe it’s just in the context of buzzword fatigue and wondering “how many different approaches to software have acronyms that end with DD?”  Whatever your level of cynicism, or lack thereof, BDD is worth a look.

A lot of my work over the last few years has involved coaching and mentoring on the subject of writing clean code, and I often tell initially skeptical developers that they should be writing methods that BAs and managers could more or less read (in places pertaining to business logic, anyway).  This isn’t as far-fetched as it sounds.  Think of a bit of code that looked like this.

Would it really be such a stretch to imagine a non-technical person being able to look at this and understand what was happening? Take an order to be evaluated, look through each of its line items, and check to see if the product they contain is in stock. You don’t need to be a programmer to have an idea of what’s happening here.

BDD From 10,000 Feet

BDD in essence, is taking this idea and expanding upon it by making domain-oriented conversation a part of software acceptance.  Don’t worry about “how” just yet.  Suffice it to say that you and various non-technical stakeholders can sit down together and write tests, in plain English, that can be run to demonstrate that system requirements are being met.  That’s pretty powerful.


Read More


The Architect Title Over-Specialization

Sometimes in the month or so after New Years, things pop into my head as “micro-resolutions.” Basically, it’s stuff that I ought to start doing that doesn’t rise to the level of importance of altering my life. One such thing is balancing the sorts of posts that I make here. I want to start getting a little more even between how-to/coding, “life of a programmer” posts, and answering reader questions. Toward that end, here’s a reader question.

You’ve mentioned the fact that you don’t like the title “architect”. I agree with you because architect has different meanings for different organizations.

I have [seen] that it can involve writing code, designing UML diagrams or just write Word documents.

Don’t you think that a developer should be [a] programmer who is also an architect and a problem solver?

In my career, I’ve held all of these job titles, so it is with some degree of admitted hypocrisy that I offer my honest opinion.  This is certainly a subject that I’ve covered in the past, and covered from a variety of angles.  It’s no secret that I don’t put a lot of stock into job titles in general.  But I don’t know that I’ve ever, specifically, held forth on the difference between architects and developers, either in terms of what I perceive it to be or what I think that it should be.  The question here, as I read it a little between the lines, might be rephrased as, “shouldn’t every developer wear the architect hat” or, perhaps, “shouldn’t architecture be any developer’s responsibility?”

Simply put, my answer to that is, “yes.”

Yes, every developer should be a programmer should be an architect and problem solver.  Yes, every developer should wear the architect hat.  Yes, all developers should take responsibility for ‘architecture.’  Now, with that out of the way, I’d like to dissect the architect-programmer distinction a bit.  And in this dissection, I think we’ll get to why there’s so much of the fuzziness alluded to in the reader question around what the term actual means.

Consider programmer/software engineer versus architect as a study in contrasts (I used this post by Simon Brown as a research point for what people perceive to be the differences between architects and developers).

  • Focus scope: programmers focus on details while architects focus on “the big picture.”
  • Leadership: programmers are led and architects lead.
  • Seniority: architects have been doing it longer than programmers.
  • Cachet: architects are important visionaries while programmers do relative grunt work.
  • Tech Selection: architects choose while programmers live with the choices.
  • Skill: architects are more technically skilled than programmers.
  • Code: architects write less code on average than developers.
  • Organizational interaction: architects deal more with “the business” in meetings than programmers.
  • Pay: architects make more than programmers.
  • Value (status): see the last bullet and understand that an architect is more valuable than a programmer.

This is how the industry at large perceives this distinction.  Architects are more tenured, important, valuable technical people that are in high demand, but often too important to do the thing that earned them their stripes (writing code).  It’s confusing and even contradictory, and this intrinsic role-fuzziness is what leads to the lack of standard across the board.  It’s why architects in some organization churn out UML diagrams while architects in others are indistinguishable from software developers except by job title.


Read More


Chess TDD 57: Finished Threat Evaluator

Once again, it’s been a while since the last episode in the series.  This time the culprit has been a relocation for the remainder of the winter, which meant I was dealing with moving-like logistics.  However I’m holed up now in the south, where I’ll spend the winter working on my book, working remotely, and hopefully wrangling this Chess TDD series to a conclusion.  In this episode, I finished threat evaluator, or at least got pretty close.  I called it a wrap around the 20 minute mark and without having written additional unit or acceptance tests to satisfy myself that it works in a variety of cases.  It now correctly understands that some moves aren’t threatening (e.g. pawn moving straight ahead) and that pieces of the same color do not threaten one another.

Also, a quick editorial note.  There’s been some pretty intense wind here in Louisiana, and the power went out around the 18:00 minute mark.  I was surprised that all of the screencasting was saved without issue, but that VS barfed and filled my source file with all sorts of nulls.  I had to revert changes and re-do them by hand prior to picking up where I left off.  So it’s conceivable that a word might be spelled slightly differently or something.  I’m not pulling a fast one; just dealing with adverse circumstances.

What I accomplish in this clip:

  • Finished threat evaluator (initial implementation).
  • Won a decisive battle in the age old, man vs nature conflict.

Here are some lessons to take away:

  • Save early and often.
  • Writing a test is a good, exploratory way to get back up to speed to see where you left off with an implementation.  Write a test that needs to pass, and then, if it fails, make it pass.  If it passes, then, hey, great, because it’s a good test to have anyway.  This (writing tests to see where you left off) is not to be confused with writing a test that you expect to fail and seeing it pass.
  • Anything you can do to tighten up the automated test feedback loop is critical (like NCrunch).  The idea here is to get in the habit of using unit tests as the quickest, most efficient way to corroborate or disprove your understanding of the code.  Run experiments!
  • If, while getting a red test green, you have an idea for a more elegant refactoring, store that away until you’ve done something quick and simple to get to green.  Don’t go for the gold all at once.  Get it working, then make it elegant.


A Players Don’t Hire A Players — They Partner with A Players

There have been a few strands of thought dangling lazily in my mind for a while now.  Over the last year or two, they’ve threatened, on occasion, to become blog posts, but it never quite worked out.  But today enough of them came together to make the resultant rant semi-coherent, as opposed to incoherent.  So, as they say, there’s no time like the present.

Tonight, someone on social media linked to this post about hiring.  It started off by saying that a record is being set for the increase in hiring software developer in the coming six months.  It then went on to describe variance in the assembly line hiring processes of tech titans such as Google, Facebook, Microsoft, and, quizzically, Yahoo, among others.  I was hard pressed to divine a thesis from the piece, but it talked about the hoops through which one must jump to work for these places, how long the interview process takes, and how people feel about the interview process.  If I had to summarize the byline, it’d be, “tech companies, more desperate than ever to hire, still pretending to be in a position of strength.”  Let’s put a pin in that, though.

Last night, someone on social media linked to something that led me to this bit of corporate boilerplate masquerading as an enthusiastic blog post on medium.  If I had to give this one a byline, it’d be, “we’re like totally awesome and we like, love people that are, like totally awesome, and like 10x productivity and like Steve Jobs, and like awesomely awesome awesomeness!”  I mean, for God’s sake, it says “great over good” in the first 25 words, as if it were penned by Bill Lumbergh himself.  “Umm. yeah… one of our corporate values is greatness… so, if you could just go ahead and come in on Sunday, that’d be greeeeeaaaaat.”


“A Players” and Who They Hire

It then goes on to reference the 10x developer canard and says that to be an order of magnitude more productive than others requires having standards, being curious, and realizing that anything is possible with the introduction of caveats.  (As an aside, the first two things merit an eye-roll, but the last one is pretty insightful, in my opinion).  It’s a standard snoozefest from some mediocre company’s “careers” page, lacking only the highly ethnically diverse stock photos.  And then, there’s the Steve Jobs quote.

Read More


What To Avoid When Doing Code Reviews

Editorial Note: I originally wrote this post for the SmartBear blog.  You can see the original here, at their site.  Go on over and check out their site!

Years ago, I had a senior software developer role in a shop where code review was part of the standard workflow. The way the review process worked was that anyone writing code had to submit the code for review to one of the senior developers of their choosing.

Over the course of time, I began to notice something interesting and a bit flattering: I was picked a lot to do reviews.  When I first got an inkling of this trend, I simply thought I was flattering myself, but then I started to keep track and I realized that there was a definite trend.  What was going on?

Was I an “easy grader” or a pushover?  Was it just by chance?  Was it that people thought I was some kind of legendary, super-developer?  Turns out it was none of these things.


In search of the answer, I started to pay more attention to the nature of code reviews offered by other senior developers.  In doing this, I came to realize that the answer lay not as much in what I was doing, but in what they were doing.  Specifically, they were doing things that I wasn’t doing, and those actions were causing others to seek out my reviews.

This phenomenon was revealing to me, so I made a point to pay attention to the actions of different reviewers among the senior developers, and line them up with how much people sought out or avoided them for code review.  Making these observations taught me valuable lessons about what to avoid when doing code reviews.

Read More