DaedTech

Stories about Software

Sep
25

By

Defining Developer Collaboration

Category: The Life of a Programmer Tags: , | 1 Comment

Editorial Note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re there, take a look around at the pieces written by other authors as well.

A certain ideal of rugged individualism has always permeated programmer culture, at least in some circles. It’s easy enough for writing code to be a highly solitary activity. There’s a clear set of rules, output is a function of input, feedback is automated, and the profession tends to attract night owl introverts in many cases.

The result is a history punctuated by tales of late night, solo efforts where someone stares at a computer until overcome by sleep. Obsessed, brilliant hackers expend inconceivable efforts to bring amazing open source tools or useful libraries into existence. It squares with movies, popular culture, and our own knowledge of our profession’s history.

SuperFastTyping

And yet, how many significant pieces of software are developed this way anymore? This ideal was born into a world where complex software might have required 10 thousand lines of code, but does it carry forward in a world where 10 million lines are common? Even projects started by individuals on a mission tend to wind up on Github and to gather contributors like a snowball rolling down a mountain.

Today’s technical landscape is a highly complex, highly specialized, and highly social one. In a world where heroic individual contributions are increasingly improbable, collaboration becomes the name of the game. Like it or not, you need other people to get much done because the work and the breadth of knowledge tends to be too much for any one person.

Defining Collaboration for Developers

I’ll spare you the obligatory, “Webster’s Dictionary defines collaboration as…” It means what you think it means: people working together. I’d like, instead, to establish some axiomatic ground rules in applying the term to the world of software development.

The first requirement is, of course, that you need to have more than one human being involved to consider the effort to be collaboration. The mechanisms, protocols and roles can vary widely, but table stakes require more than one person.

The second requirement is that the participants be working toward a shared goal. Without this, a bunch of people in a coffee shop could be said to be ‘collaborating’ simply by virtue of colocation and the occasional, polite interaction. Collaboration requires multiple people and it requires them to be united in purpose for the activity in question.

A final and developer-oriented requirement is that the participants must be working on the same work product (i.e. codebase). Again, consider a counter-example in which iOS and Android developers could be said to be ‘collaborating’ since there are more than one of them and they’re united in the purpose of improving users’ smartphone experience. Their shared purpose has to bring them together to work on the same actual thing.

Really, though, that’s it. More than one person, united in purpose and working on the same thing, are necessarily collaborating. Whether they do it well or not is another matter.

Read More

Sep
22

By

Put a Little NDepend in your Visual Studio

Category: .NET Tags: , |

Editorial Note: I originally wrote this post for the NDepend blog.  Check out the original here, at their site.  If you like posts on the topics of static analysis and software architecture, check out the rest of the posts while you’re over there.

The software development world is filled with what I think of as “Coke-Pepsi” debates. This is how my brain categorizes debates over preference that are almost entirely subjective. There is no right or wrong answer to “is Coke or Pepsi better?” The answer is, “whichever one you like better.”

Examples abound in the software world. Should you use a heavyweight IDE or a lightweight text editor? Which OOP language is ‘the best?’ And, speaking of OOP, should you use an OOP language at all, or should you use a functional one? Pascal casing or camel? The list goes on, but these sorts of things generally boil down to the comfort and preferences of the person or team.

It would be tempting to paint NDepend Standalone versus NDepend’s Visual Studio plugin with this brush. And, while I think you could make a pretty legitimate case that this too, is simply a matter of preference, I’d like to do a thought exercise today in which I lobby in favor of the integration approach. In my opinion, there are enough advantages that I might be able to sneak this one out of the Coke-vs-Pepsi realm.

pepsi-v-coke1

What’s The Difference?

First of all, I should probably explain a bit more about the difference. NDepend standalone runs like any standard, windows desktop application. In order to use it, you’d launch it and use it to query your code base, run reports, visualize your architecture, etc. If you wanted to modify your code and use NDepend simultaneously, you would have two open Windows that you would alt-tab between.

As a plugin, NDepend runs as if it were a part of Visual Studio itself. Visual Studio has a plugin-supportive architecture that allows third party tool authors to write plugins that behave this way. To users of the plugins, the integration is totally seamless. So for all intents and purposes, NDepend’s Visual Studio plugin makes NDepend a first class part of Visual Studio. Thus everything you do with NDepend and your code all happens in the same place: Visual Studio.

Why Is This Better?

I’d imagine the first thing that occurs to you is the lack of needing to alternate between two windows. And I submit that this is, in fact, an advantage, though this advantage only scratches the surface. Logistically, there is less friction in use when you don’t need to constantly context switch between two windows. And, even if you prefer to separate the concerns out into multiple windows (say, if you have multiple monitors), you can still do this inside of Visual Studio.

Read More

Sep
20

By

5 Reasons Architect and Developers Argue

Category: The Life of a Programmer Tags: | 12 Comments

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, check out NDepend and download a trial.

There’s a cute term for a blog post or article that advertises, in its title, a number of points of interest. For example, “9 Tips for Getting out of Debt,” as a title would quality. This is called a “listicle,” which is a conjoining of list and article into one word (though, for me, this somehow manages to evoke the vague image of someone licking an icicle).

This template is not normally my style, but I thought it might be fun to try it on and see how it goes. The topic about which I’d like to talk today is the various vectors for architect-developer tension and this seems, somehow, uniquely suited to the listicle format.

Where the developer role is pretty standard, the architect role is often vague in its definition and can vary widely from organization to organization. In some shops, the architect is just the longest tenured developer, whereas in others the architect is a specialized role that generates mountains of UML diagrams.

The ambiguity and variance, combined with the fact that architect is nominally ‘above’ developers, creates a breeding ground for interpersonal friction. While not always present, this is a common theme in the industry. So, I’d like to examine 5 reasons for strife between developers and architects.

Spies

Read More

Sep
18

By

Wherefore Art Thou, Tech Debt?

Category: You Asked For It | 10 Comments

About a month ago, I re-posted something that I had written about tech debt for the Infragistics blog.  This turned out to be a popular post, and it generated some reader questions.  Today, I answer one of those questions, which basically amounts to “wherefore tech debt?”

What generates tech debt?

No doubt, you’ve heard the Shakespeare-as-Juliet ask, “Romeo, Romeo, wherefore art thou, Romeo?”   Most people imagine Juliet, standing on the balcony and offering a maudlin request blindly into the night — “where are you, dude?”  Interesting bit of trivia.  Juliet does not ask where Romeo is, but why he is.  She poses a much more interesting question.  “Why do you exist?”

Accordingly, this post concerns the wherefore of tech debt.  Why do we find ourselves saddled with this stuff?

JuliEt

Read More

Sep
15

By

Why Automate Code Reviews?

Category: Language Agnostic Tags: , | 10 Comments

Editorial Note:  I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  This is a new partner for whom I’ve started writing recently.  They offer automated code review and documentation tooling in the .NET space, so if that interests you, I encourage you to take a look.

In the world of programming, 15 years or so of professional experience makes me a grizzled veteran.  That certainly does not hold for the work force in general, but youth dominates our industry via the absolute explosion of demand for new programmers.  Given the tendency of developers to move around between projects and companies, 15 years have shown me a great deal of variety.

Lifer

Perhaps nothing has exemplified this variety more than the code review.  I’ve participated in code reviews that were grueling, depressing marathons.  On the flip side, I’ve participated in ones where I learned things that would prove valuable to my career.  And I’ve seen just about everything in between.

Our industry has come to accept that peer review works.  In the book Code Complete, author Steve McConnell cites it, in some circumstance, as the single most effective technique for avoiding defects.  And, of course, it helps with knowledge transfer and learning.  But here’s the rub — implemented poorly, it can also do a lot of harm.

Today, I’d like to make the case for the automated code review.  Let me be clear.  I do not view this as a replacement for any manual code review, but as a supplement and another tool in the tool chest.  But I will say that automated code review carries less risk than its manual counterpart of having negative consequences.

Read More

« Older Posts
Newer Posts »