Tim Barcz : Musings

Poor Design Is Not a Bug

Tim Barcz — Fri, 26 Nov 2010 03:37:18 GMT

Ayende recently posted a an article titled “Where is the bug”. While reading the comments, I was disappointed by some of the answers to Ayende’s request to find the bug. Here are two of the comments that stood out to me:

“You could argue the biggest bug is the use of a switch statement as it violates OCP.“
“The use of a switch statement is a bug in itself.“

What bothers me so greatly is people’s inability to separate design discussion with bugs. A bug is defined on Wikipedia as:

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways

The two comments above don’t attempt to solve the bug and instead take an “ivory tower approach” to the problem (more befuddling is that removing the switch in favor of something else would leave the bug in place). This bugs me because we (as an industry) continue to care very little about the output and meeting of customer/business needs and more about code structure and semantics than actually working code.

Let me state for the record, it is perfectly acceptable to talk about code structure and design but please let’s not confuse a bug – an actual error or flaw in code – with poor design.

(I think it’d be humorous for Ayende to post some perfectly fine code and ask “Where’s the bug” and watch people trip over themselves trying to find something wrong)

Are You Playing Checker or Chess? - YAGNI Revisited

Tim Barcz — Mon, 15 Mar 2010 05:08:37 GMT

This past Saturday I had an early morning coffee with a friend. He’s an entrepreneurial type – a big thinker who moves at a fast pace and is always thinking ahead. One question he asked of me, “Are you playing checkers or chess?”.

The question was asked around business and career but I could not help but think of the implications to software.

In the agile software world we often use the mantra…”do the simplest thing that works”. I have found that I cringe at the usage of that statement at certain points (when honest - even at my own usage at times upon later reflection). Really, if we step back and honestly evaluate ourselves, how often do we really implement the simplest thing that works. My opinion is that it’s often used as an excuse to get get out of work - a “wild card” of sorts that’s pulled out when convenient.

With “the simplest thing that works”, developers associate the term YAGNI – You Ain’t Gonna Need It. While very often true – you really don’t need that feature (studies have demonstrated and confirmed) – I see times where people confuse YAGNI and the agile principle of “the simplest thing that works”. What’s the difference?

Chess versus checkers my friend. Checkers is a pretty simple game with few rules and even fewer game pieces. Chess however has several game pieces, each of which has their own movements and rules associated with them. The types of discussions and strategies that exist around chess do not exist around checkers. Put simply, chess is much more complex than checkers. Checkers is really treated on a move-by-move basis whereas chess is far more strategic, where moves are setup far in advance of their execution.

When talking about “the simplest thing that works” we have to be careful to not be playing checkers. Play chess instead. Make a small, single move that moves you closer to some strategic end. Like it or not, many waterfall processes are playing chess – trying to anticipate every outcome or piece of functionality and adjust/account for it. What the waterfall practitioner fails to see is the inevitable change. Many agile adopters start playing checkers, making small move after small move, assuaging fears of downstream problems with the comfort that their doing the simplest thing that works.

Therefore, have a strategy, a end in mind, and then do the simplest thing that works that moves you closer to that end. Note however that this may not always be the absolute simplest thing that works.

Confessions of a First Time Manager

Tim Barcz — Sun, 13 Dec 2009 04:10:39 GMT

Many months ago I wrote a letter to upper management about principles of software development and the ways in which should build software. Since that time my role has changed within the company and for the first time in my career I’m managing a significant number of people (at a previous company I was an R&D Manager but the team was much smaller).

Below are a few observances/realizations I’ve had in the months since I’ve made the transition that I want to share with you:

Just cause you’re the manager doesn’t mean you know everything – Just because someone has tapped you to lead the team doesn’t mean “you’ve arrived”. You don’t automatically go from individual contributor to all-knowing edict maker.
Don’t Relax/Stay involved – Too many managers think because they’ve “arrived” they no longer need to keep pushing themselves. They think they are afforded some special privileges or don’t have to abide by the same rules others are held to. Not wise.
Rely on your team – This one is often hard. It was likely your contributions as in individual contributor that got you noticed for the management position and it’s often hard for an individual contributor accept the role change and not want to tackle challenges individually or continue to contribute. As a manager you’ll have to rely on your team to see the same level of success as a manager as you presumably did as an individual contributor. You’re no longer measured on what you do but rather how your entire team performs. This one is admittedly hard for me and I’m growing into this more and more every day.
Build your team – As an individual contributor you were primarily responsible for just one person, yourself. As project lead or a team lead you’ll have more responsibility but likely you won’t have people reporting directly to you. As a manager you’re now responsible for everyone on your team and giving them the opportunity to be the best they can. Give people the freedom they need to do great things.
Be honest - Don’t lie, shade the truth, or embellish. When you mess up, fess up, I believe the team will respect you more for it. ‘nuff said.
Never ask your team to do something you wouldn’t do yourself – Managers who require/ask team members to do something they wouldn’t do themselves are being unfair. Asking your team to work late while you get to leave every day at 5:00 is an amateur move. Asking the team to give up the weekend might be a necessity at times. Just make sure if you ask, you’re right there alongside of them.
Don’t be a bottleneck to change – The team shouldn’t always move at the speed of the manager. In general just because you don’t understand something doesn’t mean it shouldn’t be adopted. If you cut your teeth on VSS and were a ninja in VB.NET but now your team wants to move all projects to C# and this new thing called Git, don’t blindly say no. Technology moves fast, if you have a trustworthy team, you’re going to have to let go a bit and rely on the team (#3). Remember, you don’t know everything (#1) and you need build your team (#4), sometimes that may mean doing or trying something you don’t quite understand.
Don’t be afraid to push for change – While you shouldn’t be a bottleneck to change you shouldn’t be afraid to push for it either. As a manager you typically have a greater visibility to the team or the process and if you see something that could be improved you shouldn’t necessarily wait for someone on your team to bring it forward. You’re still part of the team
Hiring/Firing Sucks – Movies make firing seem like an easy thing to do and an ego-boosting power-trip. It couldn’t be further from the truth. The days I’ve had to let people go I’ve rarely slept the night before. There’s nothing enjoyable about the process of taking away someone’s livelihood. Hiring can be fun, but most often it’s time consuming and all the time you spend interviewing is wasted except on the one person you hire.

You’ll notice that many are intertwined and I think at the heart of many of these is pride. Pride is a dangerous beast, avoid it at all costs. Whether it means you have a trusted friend or colleague keep you in-check or you do frequent self-assessments, don’t let pride seep it.

Please note that these are my personal observances that I’ve taken mental note of while on this journey. Your mileage may vary.

Don't Overcomplicate The Issue

Tim Barcz — Tue, 03 Feb 2009 16:00:06 GMT

I felt compelled to write after seeing this very same issue come up twice in the last week or so, once for a fellow developer and today for me.

The Problem

We use a DataSet for assistance with testing our data layer (think NDBUnit). The problem we have is that when you generate the DataSet the XSD created contains all these table adapters that bloat the file, in our app the file bloats to about five times the regular size. We've found that deleting the table adapters on the file makes the file open up so much faster. However, every time we make a change to the database schema we have to regenerate the DataSet so that it matches the schema. As the table count has grown deleting these table adapters by hand has grown wearisome. All this is merely set up for me over-fixing the problem.

My First (Wrong) Thought

I thought to myself, "hey this is XML I'll just load up and XML document and query out the nodes (TableAdapters) I don't need and remove them from the document and save it back." While writing a quick bit of code I found writing more code than I needed (at this point I was only at 6 lines). Despite the file being XML, I don't need to treat it as XML. Understand that nothing about getting rid of the TableAdapters relies on the "XML-ness" of the file, it's all just text. Reminding myself of that...here's what I came up with...

The Second (Correct) Solution

Simply treat the file as text and remove the piece you need, the only caveat is that I'm dealing with XML and so if I remove a "piece" I have to remove the whole "piece" (where "piece" means XmlNode). The solution below simply matches TableAdapter nodes and replaces them with empty text. Simple.

   1: var path = @"C:\dev\sandbox\Website\src\IntegrationTests\TestData\Database.xsd";

   2: var text = File.ReadAllText(path);

   3: File.WriteAllText(path, Regex.Replace(text, "<TableAdapter.*?>.*?</TableAdapter>", "", RegexOptions.Singleline));

The Point

The point is the first solution, while correct, was more complex than it needed to be. Using a little bit of RegEx to wipe clean certain nodes, I get exactly what I want in three lines of code. Moral of the story? Don't overcomplicate what doesn't need to be.