My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
TeamCity is a build server from JetBrains that I'm starting to like. It checks your code out, builds it, and runs your unit tests against the compiled source code (among other things), continuously integrating your code each time someone checks-in a change to the repository (or on-demand, if you'd like). Oh, and it's a bit faster than CruiseControl as well (At least for me).

It's free for many applications - those where you won't use more than 20 user accounts, 20 build configurations, 3 build agents, and don't need anything more than the standard web-based authentication interface. (A build configuration is a way of building using a build agent - e.g., you could build based on a .NET solution file, ANT file, or many other ways. A build agent appears to be the computer itself, though I'm not sure of that yet.)

In any case, there is an "enterprise" license that costs a couple of thousand dollars to get you around most of those limitations. The only exception is the limitation to three build agents - you can buy extra licenses for that at $299 a pop. I can't foresee the need for even two, but that might be because I have yet to see all the functions they serve.

Anyway, if you've been paying attention at least partially, you'll know I'm a huge fan of the DRY principle, especially as it relates to source code. In that case, you wouldn't be surprised to learn that one of my favorite features is this:

Screen capture showing TeamCity's code duplication detection

I haven't yet found a way to make the build fail for duplication, but seeing the reports is nice. I was also a bit disappointed it didn't catch code like this:

public int add(int x, int y) { return x+y; }
public int anotherAdd(int z, int a) { return z+a; }

But, it's nice to know it will at least catch copy-and-paste reuse.

I was set up and running my duplication checks in a few minutes, but finding everything you need is not as painless (setup is mostly painless, finding reasons for build failure and editing is not as easy). It's not hard, by any stretch of the imagination, but they set such a high standard on the "add" part that even the minor annoyances I encountered on the rest seemed large. A lot of that is being new not just to the technology, but some of the terminology they used as well.

Anyway, I've not dived in deep enough to see how or if it might work for other languages or platforms, but if you're using Java or .NET, I'd recommend you give it a try.

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

I was introduced to the concept of making estimates in story points instead of hours back in the Software Development Practices course when I was in grad school at UH (taught by professors Venkat and Jaspal Subhlok).

I became a fan of the practice, so when I started writing todoxy to manage my todo list, it was an easy decision to not assign units to the estimates part of the app. I didn't really think about it for a while, but recently a todoxy user asked me
What units does the "Estimate" field accept?

Outsourcing is not going away. You can delude yourself with myths of poor quality and miscommunication all you want, but the fact remains that people are solving those problems and making outsourcing work.

As Chad Fowler points out in the intro to the section of MJWTI titled "If You Can't Beat 'Em", when a company decides to outsource - it's often a strategic decision after much deliberation. Few companies (at least responsible ones) would choose to outsource by the seat of their pants, and then change their minds later. (It may be the case that we'll see some reversal, and then more, and then less, ... , until an equilibrium is reached - this is still new territory for most people, I would think.)

Graph showing much more growth in IT outsourcing with statistics from 2006.
Chad explains the situation where he was sent to India to help improve the offshore team there:
If [the American team members] were so good, and the Indian team was so "green," why the hell couldn't they make the Indian team better? Why was it that, even with me in India helping, the U.S.-based software architects weren't making a dent in the collective skill level of the software developers in Bangalore?

The answer was obvious. They didn't want to. As much as they professed to want our software development practices to be sound, our code to be great, and our people to be stars, they didn't lift a finger to make it so.

These people's jobs weren't at risk. They were just resentful. They were holding out, waiting for the day they could say "I told you so," then come in and pick up after management's mess-making offshore excursions.

But that day didn't come. And it won't.
The world is becoming more "interconnected," and information and talent crosses borders easier than it has in the past. And it's not something unique to information technologists - though it may be the easiest to pull-off in that realm.

So while you lament that people are losing their jobs to cheap labor and then demand higher minimum wages, also keep in mind that you should be trying to do something about it. You're not going to reverse the outsourcing trend with any more success than record companies and movie studios are going to have stopping peer-to-peer file sharing.

That's right. In the fight over outsourcing, you, the high-paid programmer, are the big bad RIAA and those participating in the outsourcing are the Napsters. They may have succeeded in shutting down Napster, but in the fight against the idea of Napster, they've had as much strategic success as the War on Drugs (that is to say, very little, if any). Instead of fighting it, you need to find a way to accept it and profit from it - or at least work within the new parameters.

How can you work within the new parameters? One way is to "Manage 'Em." Chad describes several characteristics that you need to have to be successful with an offshore development team, which culminates in a "new kind" of PM:
What I've just described is a project manager. But it's a new kind of project manager with a new set of skills. It's a project manager who must act at a different level of intensity than the project managers of the past. This project manager needs to have strong organizational, functional, and technical skills to be successful. This project manager, unlike those on most onsite projects, is an absolutely essential role for the success of an offshore-developed project.

This project manager possesses a set of skills and innate abilities that are hard to come by and are in increasingly high demand.

It could be you.
Will it be?

Chad suggests learning to write "clear, complete functional and technical specifications," and knowing how to write use cases and use UML. These sorts of things aren't flavor-of-the-month with Agile Development, but in this context, Agile is going to be hard to implement "by the book."

Anyway, I'm interested in your thoughts on outsourcing, any insecurities you feel about it, and what you plan to do about them (if anything). (This is open invitation for outsourcers and outsourcees too!) You're of course welcome to say whatever else is on you mind.

So, what do you think?

Side Note: Posted Thursday instead of Friday because I'm off to Lone Star Ruby Conference in the morning. Hit me up on twitter or contact me if you're going to be there.

If we accept the notion that we need to figure out how to work with outsourcing because it's more likely to increase than decrease or stagnate, then it would be beneficial for us to become "Distributed Software Development Experts" (Fowler, pg 169).

To do that, you need to overcome challenges associated with non-colocated teams that exceed those experienced by teams who work in the same geographic location. Chad lists a few of them in this week's advice from My Job Went To India (I'm not quoting): More...

This is the tenth and final post in a series of answers to 100 Interview Questions for Software Developers.

The list is not intended to be a "one-size-fits-all" list. Instead, "the key is to ask challenging questions that enable you to distinguish the smart software developers from the moronic mandrills." Even still, "for most of the questions in this list there are no right and wrong answers!"

Keeping that in mind, I thought it would be fun for me to provide my off-the-top-of-my-head answers, as if I had not prepared for the interview at all. Here's that attempt.

Though I hope otherwise, I may fall flat on my face. Be nice, and enjoy (and help out where you can!).


For the last few months, I've been having trouble getting out of "next week" mode. That's what I call it when I don't know what I'll be working on outside of the next week at any given time. It's not necessarily a bad thing, but when you're working on projects that take longer than a couple of weeks, it doesn't let you keep the end in sight. Instead, you're tunneling through the dirt and hoping you've been digging up instead of down. More...

Last week, hgs asked,
I find it interesting that lots of people write about how to produce clean code, how to do good design, taking care about language choice, interfaces, etc, but few people write about the cases where there isn't time... So, I need to know what are the forces that tell you to use a jolly good bodge?
I suspect we don't hear much about it because these other problems are often caused by that excuse. And, in the long run, taking on that technical debt will likely cause you to go so slow that that's the more interesting problem. In other words, by ignoring the need for good code, you are jumping into a downward spiral where you are giving yourself even less time (or, making it take so long to do anything that you may as well have less time). More...

I'm not talking about Just-In-Time compilation. I'm talking about JIT manufacturing.

When you order furniture, it likely gets assembled only after the order was received. Toyota is famous for doing it with cars. You can do it yourself with JIT published books. On top of that, Land's End offers custom tailored, JIT manufactured clothing.

It's easy to say, "yes, we can publish software in the same manner." Every time we offer a download, it's done just in time. This post was copied and downloaded (published) at the moment you requested it.

That's not what I'm talking about either. More...

Last week I posted about why software developers should care about process, and how they can improve themselves by doing so. In the comments, I promised to give a review of what I'm doing that seems to be working for me. So here they are - the bits and pieces that work for me. Also included are new things we've decided to try, along with some notes about what I'd like to attempt in the future. More...

In this week's advice from MJWTI, "The Way That You Do It," Chad Fowler talks about process and methodology in software development. One quote I liked a lot was:
It's much easier to find someone who can make software work than it is to find someone who can make the making of software work.
Therefore, it would behoove us to learn a bit about the process of software development. More...

Mingle is a project management tool that is supposed to be the first commercial product running on JRuby on Rails, and ThoughWorks just announced its release.

I first heard of it back at NFJS about a month ago, and went online to get a preview copy. I had hoped to review it on the blog, but that never got done. In any case, you can now get a copy and try it for yourself. It's probably pretty good. I mean, it is from ThoughtWorks.

A while ago Ted Neward was reading The 33 Strategies of War and decided to relate those strategies of war to software development.

This weekend he put up the first in the series of 33: Declare War on Your Enemies (The Polarity Strategy).

In any case, I like the idea. Having had some education in politics and computer science, this appealed to me even more than it might have, but I'd think I'd recommend reading it anyway.

My favorite quote?
We will not ship code that fails to pass any unit test... Well, then, we'll not write any unit tests, and we'll have met that goal!
What do you think of viewing software projects as conflict?

A phrase that Venkat likes to use sums up my view on software religions: "There are no best practices. Only better practices." That's a powerful thought on its own, but if you want to make it a little more clear, I might say "There are no best practices. Only better practices in particular contexts." This concept tinges my everyday thinking.

As I mentioned before, I'm blind to rules that "always apply" in software development. This post about fundamentalism in software methodology got me thinking about a post I had meant to write up a while ago, which basically turned into this one. More...

There is a seemingly never-ending debate (or perhaps unconnected conversation and misunderstandings) on whether or not the software profession is science or art, or specifically whether "doing software" is in fact an engineering discipline.

Being the pragmatist (not a flip-flopper!) I aspire to be, and avoiding hard-and-fast deterministic rules on what exactly is software development, I have to say: it's both. There is a science element, and there is an artistic element. I don't see it as a zero-sum game, and its certainly not worthy of idolatry. (Is anything?) More...

Many of us know the value of deferring commitment until the last responsible moment (in the past, I've always said "possible," but "responsible" conveys the meaning much clearer, I think). In fact, it is the underlying principle of YAGNI, something more of us are familiar with.

The argument goes something like: If you do not wait to make decisions until they need to be made, you are making them without all of the information that will be available to you at the time it does need to be made. Now, you may get lucky and be right, but why not just wait until the decision has to be made so you can be sure you have all the information you can get?

I find it to be very sound advice.

I missed this the other day on InfoQ, but they have an article by Chris Matts and Olav Maassen entitled "'Real Options' Underlie Agile Practices" that explains the thinking behind this in detail, relating it to Financial Option Theory and some psychology. It's a good article explaining how "Real Options" forms the basis of A/agile thinking, and had some ideas I hadn't heard before about keeping your best developers free as they represent more "options" and you shouldn't commit them too early. Also, they can create options by mentoring less experienced developers (through pairing perhaps). There's a lot more than this simple summary, and I consider it worth a read.

Any thoughts?

Want to get a report of a certain session? I'll be attending No Fluff Just Stuff in Austin, Texas at the end of June. So, look at all that's available, and let me know what you'd like to see.

I haven't yet decided my schedule, and it's going to be tough to do so. I'm sure to attend some Groovy and JRuby sessions, but I don't know which ones. In any case, I want to try to leave at least a couple of sessions open for requests, so feel free to let me know in the comments what you'd like to see. (No guarantees though!). Here's what I'm toying with so far (apologies in advance for not linking to the talks or the speakers' blogs, there are far too many of them =)): More...

Kenji HIRANABE (whose signature reads "Japanese translator of 'XP Installed', 'Lean Software Development' and 'Agile Project Management'") just posted a video (with English subtitles) of himself, Matz (creator of Ruby), and Kakutani-san (who translated Bruce Tate's "From Java To Ruby" into Japanese) to his blog. According to Matz (if I heard correctly in the video), Kenji's a "language otaku," so his blog may be worth checking out for all you other language otakus (though, from my brief look at it, it seems focused between his company's product development and more general programming issues).

In any case it's supposed to be a six part series where the "goal is to show that 'Business-Process-Framework-Language' can be instanciated as 'Web2.0-Agile-Rails-Ruby' in a very synergetic manner, but each of the three may have other goals." The first part discusses the history of Java, Ruby, and Agile. I found it interesting and am looking forward to viewing the upcoming parts, so I thought I'd link it here.

InfoQ has released yet another minibook of interest to me: Patterns of Agile Practice Adoption: The Technical Cluster.

The book discusses questions for the benefit of people who are trying to adopt Agile. In particular, they list "'Where do I start?', 'What specific practices should I adopt?', 'How can I adopt incrementally?' and 'Where can I expect pitfalls?'" as some of the main ones people have.

Browsing the Table of Contents, it looks like the patterns they discuss are many of those you'd expect that people with good development practices are familiar with: automated unit and functional testing, continuous integration, simple design, and collective code ownership. I haven't yet taken the time to read it, but I plan to when I've got some free time. In any case, it looks like at least it would be a good introduction to these things for those who are interested.

I think that as developers, we too often ignore business objectives and the driving forces behind the projects on which we work. Because I'd like to know more about how to think and analyze in those terms, I decided to take a course about Management Information Systems this semester in grad school. One of the papers we read particularly stuck with me, so I thought I'd share the part that did: When we undertake a risky project (aren't they all?), we should consider what competitive advantage it will give it, and if that advantage is sustainable.

To measure sustainability, Blake Ives (from University of Houston) and Gabriel Piccoli (from Cornell) identify four barriers to erosion of the advantage (this is within a framework they present in the paper, which is worth reading). The barriers are driven by "response-lag drivers," which the authors define as "characteristics of the firm, its competitors, the technology, and the value system in which the firm is embedded that contribute to raise and strengthen barriers to erosion." In any case, on to the four things we should consider: More...

Agile Houston is having their first meeting tonight. I had wanted to make it (and still will if I find time), but I've got a homework deadline tonight. I just wanted to help spread the word. If you are in Houston and aren't on their email list, you can find it here (for general discussion) or here (for announcements only). You can get details on the event (which is being held @ 6:30 PM at Ziggy's Health Grill) on their website.

For those of you far outside of Houston (Texas, USA), I apologize for boring you with useless information. =) It has been my specialty lately.

If you are using version control, what is your setup like, and why did you choose to do it that way?

In Java development, I've got a repository, and I checkout the code to my desktop, check it back in, etc. So, there is no version control on the production server, though. Of course, there is no point (that I see) to have it on the production server, since you don't need many of your source files, but only the compiled classes (I'm assuming web development here).

But in CF, you'll be using all your source files as the actual files to be run, so you might very well set up source control on the production server, and have that be your main code base (say, checking it out to your development server and editing it from there, or to your desktop). Or, do you simply run the version control on your development server, and FTP any changes to production?

There are other ways, to be sure, so if you're using version control on your ColdFusion projects, I'd like to know the different ways you have it set up, and why you chose to do it that way. Any help is appreciated!

I finally got around to watching Ron Jeffries' interview at InfoQ. Most of this is not groundbreaking new material for programmers/managers/stakeholders/vampirebats who ship "running tested features" on an short iterative basis. But, he said two things that really hit home for me:
If we fall behind on our design, what happens is: our velocity, instead of going up, will begin to tail off and ultimately crash. Almost every software developer at one time or another has worked on a program where he wants to say : "I can't put another feature into this; this program's design is so horrible that I can't add any more features to it, it's incredibly difficult."
It's a choice: now, I don't do everything I ought to do, or even everything that I'm quite confident that I have to do, and I don't think anyone does. But the more skill we could bring to this project, and the more we learn how to put those skills togetherwith other people's skills, I think that enables us to come around to do what we have to do.
How true! It's worth the 23 or so minutes it takes to watch it. Anyway, you can find the interview here.

Susan K. Land, IEEE 2nd Vice President and key contributor on the America's Army project, visited the University of Houston yesterday and gave a talk about how the AA project went from complete chaos to having a major successful release in seven months.

In a nutshell, they went from zero process (CMM Level one) to a repeatable success, CMM Level Two. This was especially impressive because the game is being developed for both public and government use, and by several different development centers around the US (I remember counting more than 10, I think). She mentioned that at one point it was so bad that when one of the companies who hosted the source repository wasn't being funded, they shut off access to it. I wanted to ask why they did business with such a company, but I thought it prudent not to seem like a jerk. (We have a government client and they just renewed their contract about four months too late, but we didn't shut down their service. We just know they work slow.)

All in all this release took seven months.

I was interested in knowing how the developers and managers responded to going from no structure, to one complete with requirements gathering, detailed analysis, coding and testing (all in separate phases, from how she described it). She said the managers were weary at first, but if the project was a success, they would be happy (it was a success). Regarding the developers, she said they actually loved it - and I can certainly see how that was the case, having worked ad-hoc before. However, I'm not a big fan of how they went about the process. She said they spent about one-and-a-half months getting the requirements down, 2.5 on detailed design, 1.5 in coding, and the rest in testing. I don't know if she meant it to sound like waterfall (she said they were more in a spiral, but it didn't sound like it), but I wondered what the "coders" were doing in the rest of the time. Were they designing?

I meant to ask if she thought it may have reduced some risk by designing some, then coding some, and so forth, but time was running low and I didn't want to be offensive. In the end, the project was a success, and if the new process got them there (which, it certainly sounds like it did), then you certainly have to tip your hat.

So hat's off to America's Army!


Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner