My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
A greedy algorithm is an algorithm that follows the problem solving heuristic of making the locally optimal choice at each stage with the hope of finding a global optimum. In many problems, a greedy strategy does not in general produce an optimal solution, but nonetheless a greedy heuristic may yield locally optimal solutions that approximate a global optimal solution in a reasonable time.
What does a greedy algorithm look like?
Images from Wikipedia illustrate the concept well. In the first one, we begin our search of the space for a maximum at point A. If we're greedy, the next highest point takes us along a path that maximizes at point (lower case) m. However, the optimal solution is at point (upper case) M.

Illustration of greedy search along a plane

If you're greedily searching (again, for a maximum) in three-dimensional space, and start in a poor position (like near the left in the image below), you'll never make it off the shorter hill onto the taller one: More...

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?

An interesting discussion going on over at programming reddit got me thinking about what features I'd like my ideal job to have. Aside from "an easy, overpaid job that will get bring me fame and fortune," here's what would make up my list:
  1. Interesting Work: You can only write so many CRUD applications before the tedium drives you insane, and you think to yourself, "there's got to be a better way." Even if you don't find a framework to assist you, you'll end up writing your own and copying ideas from the others. And even that only stays interesting until you've relieved yourself of the burden of repetition.

    Having interesting work is so important to me that I would contemplate a large reduction in income at the chance to have it (assuming my budget stays in tact or can be reworked to continue having a comfortable-enough lifestyle, and I can still put money away for retirement). Of course,the more interesting the work is, the more of an income reduction I could stand.

    Fortunately, interesting work often means harder work, so many times you needn't trade down in salary - or if you do, it may only be temporary.

    The opportunity to present at conferences and publish papers amplifies this attribute.

  2. Competent Coworkers: One thing I can't stand is incompetence. I don't expect everyone to be an expert, and I don't expect them to know about all the frameworks and languages and tricks of the trade.

    I do expect programmers to have basic problem solving skills, and the ability to learn how to fish.

  3. Sane Management: Don't make me delighted to have a broken watch. I shouldn't have to turn back the dial on it to meet deadlines. Or put more strongly, management/customers shouldn't be given the latitude to control all three sides of the iron triangle of software development.

    Scope, Schedule, and Resources. Choose two. We, the development team, get to control the third.

  4. Trust: One comment in the reddit discussion mentioned root access to my workstation and it made me think of trust. If you cannot trust me to administer my own computer, how can you trust me not to subvert the software I'm writing?

    Additionally, I need you to trust my opinion. When I recommend some course of action, I need to know that you have a good technical reason for refusing it, or a good business reason. I want an argument as to why I am wrong, or why my advice is ignored. If you've got me consistently using a hammer to drive marshmallows through a bag of corn chips, I'm not likely to stay content.

    I don't mind if you verify. In fact, I'd like that very much. It'll help keep me honest and vigilant.

  5. Personal Time: I like the idea of Google's 20% time. I have other projects I'd like to work on, and I'd like the chance to do that on the job. One thing I'd like to see though, is that the 20% time is enforced: every Friday you're supposed to work on a project other than your current project. It'd be nice to know I'm not looked down upon by management as selfish because I chose to work on my project instead of theirs.

    I wouldn't mind seeing something in writing about having a share of the profits it generates. I don't want to be working on this at home and have to worry about who owns the IP. And part of that should allow me to work on open source projects where the company won't retain any rights on the code I produce.

  6. Telecommuting: Some days I'll have errands to run, and I dislike doing them. I really dislike doing them on the weekends or in the evenings after work. I'd like to be able to work from home on these days, do my errands, and work late to make up for it. It saves the drive time on those days to help ensure I can get everything done.
There are some other nice-to-have's that didn't quite make the list above for me. For example, it would be nice to be able to travel on occasion. It would also be nice to have conferences, books, and extended learning in general paid for by the company. I'd like to see a personal budget for buying tools I need, along with quality tools to start with.

But if you can meet some agreeable combination of the six qualities above, I'll gladly provide these things myself. If you won't let me use my own equipment, and you provide me with crap, we may not have a deal.

That's my list. What's on yours?

You have a sales meeting that generates a Statement of Work. The statement of work includes a lot of fluff and a few line items. In your first development meeting with the client, you pitch the possibilities of what the system can be, thinking it's obvious the dream you're describing will require more contract hours. However, given all the fluff in the original SOW, the customer assumes it can be done under your current agreement. Subsequent meetings revise the project features downward until the customer sees the deliverable: in their eyes, it's a bottle rocket. But you've built more than you ever thought you agreed to - it's a bona fide spaceship.

Focus on your customer's feelings, be clear about deliverables, and if you don't intend to deliver the fluff, don't talk about it as if you do. Don't design contracts and project meetings around making yourself feel warm-and-fuzzy. Stroking your ego like this makes you feel like a hero who under-promised and over-delivered. Unfortunately, the customer got the opposite impression.

How is it that two groups of people experienced the same phenomenon, yet come away interpreting it world's apart?

Miscommunication and failure to manage expectations.

If you fail to communicate and verify what was understood was what you intended to say, you're liable to set expectations much higher than you can possibly deliver. That leads to pissed-off customers, or worse: past customers.

Aside: It was tempting to satisfy my desire to entitle a blog post using two clich├ęd proverbs and an OrColon: Subtitle, but I refrained from calling this "Bad Apples Don't Always Spoil The Bunch, Or: Don't Throw The Baby Out With The Bathwater." I also could have used the subtitle, "Or: A Four Course Meal To Avoiding Disaster On Your Team." Such titles are great for posting to reddit/programming, but I've had enough cheese today on my pizza.

However, so that I don't neglect the cheese lovers among us who have a craving for the moldy substance, I'll tide you over with this morsel:

Appetizer entertainment from The Osmond's aside, we can get to the salad plate of our four course meal: Jeff Atwood wrote a blog post about Dealing With Bad Apples where he quotes some of Steve McConnell's work:
If you tolerate even one developer whom the other developers think is a problem, you'll hurt the morale of the good developers. You are implying that not only do you expect your team members to give their all; you expect them to do it when their co-workers are working against them.
He goes on to quote McConnell's reporting of the data (something valuable McConnell always offers):
In a review of 32 management teams, Larson and LaFasto found that the most consistent and intense complaint from team members was that their team leaders were unwilling to confront and resolve problems associated with poor performance by individual team members. (Larson and LaFasto 1989).
All of that is to say: software developers with bad attitudes should not be tolerated for long, lest they destroy the team from the inside.

He continues, citing ways in which to identify miscreants on your team, finally concluding that
You should never be afraid to remove -- or even fire -- people who do not have the best interests of the team at heart. You can develop skill, but you can't develop a positive attitude. The longer these disruptive personalities stick around on a project, the worse their effects get. They'll slowly spread poison throughout your project, in the form of code, relationships, and contacts.
There's nothing too striking here. In fact, I didn't think twice about it until I read Brian Cunningham's response:
I agree with this wholeheartedly. But you also have to ask yourself whether there's something you could have done to prevent things from getting to this point.
Whenever a bad apple is discovered on your team, you should always consider the possibility that it could have been prevented. In many cases there's nothing you can do -- it's simply a conflict of personalities. But if you find situations where the bad apple could have been prevented, that means there's something in the management of the team that needs to be addressed. (Strong emphasis mine)
And then Jeff's words stuck out, reminding me of me:
You can develop skill, but you can't develop a positive attitude.
In my case, it was me who decided to develop the positive attitude. But that doesn't mean it couldn't have been developed by a skilled manager who noticed the problem.

Retrospective action is useful in avoiding the problems of today in the future, but often misunderstandings, miscommunication, and a lack of clear goals or motivation can be the cause of friction or a bad-apple attitude. So I take it a step further to the main course of our meal: Not only should you reflect on how the problem could have been averted upon discovery of the subversive, you should actively scan for potential problems and address them before they germinate.

It would not result in firings or team destructions, but instead focus on resolving the conflicts before they fully emerge. (Of course, if the problem is allowed to grow and fester, firings are encouraged.)

I'm not sure how to do that.

I don't personally have the answers regarding strategies for identifying problems and understanding what people really mean in conflict resolution, but I'm confident they exist. I've read as much. But I searched the all-knowing Google and didn't find the sources I sought. So at the moment, they remain outside my realm of knowledge. Therefore, I'd like to ask: What are your strategies? How do you handle problem developers or teammates? What are the reading materials discussing these issues that I'm looking for? More...

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.

You might think that "tech support" is a solved problem. You're probably right. Someone has solved it and written down The General Procedures For Troubleshooting and How To Give Good Tech Support. However, surprisingly enough, not everyone has learned these lessons. And if the manual exists, I can't seem to find it so I can RTFthing.

The titles of the two unheard of holy books I mentioned above might seem at first glance to be different tales. After all, troubleshooting is a broad topic applicable to any kind of problem-solving from chemistry to mechanical engineering to computer and biological science. Tech support is the lowliest of Lowly Worms for top-of-the-food-chain programmers.


There was once upon a time I held some affinity for Expert'sExchange. I tried hard and succeeded at becoming an expert. I thought it might look good on a resume and in fact I got a few offers of job and freelance work from it. More...

We observe that organizational structure metrics are significantly better predictors for identifying failure-prone binaries in terms of precision, and recall compared to models built using code churn, code complexity, code coverage, code dependencies, and pre-release defect measures.
(Link is to abstract page, quote is from the PDF linked to from there, chart below is from the paper as well) More...

Every day, psychological barriers are erected around us, and depending on what task they are a stumbling block for, they can be helpful or a hindrance.

Ramit Sethi wrote a guest post on personal finance blog Get Rich Slowly about passive barriers that got me thinking about passive barriers in software development, or perhaps just any easily destroyed (or erected barrier) that prevents you from doing something useful (or stupid). One example he uses that comes up a lot in my own work references email: More...

A friend of mine from graduate school recently asked if she could use me as a reference on her resume. I've worked with her on a couple of projects, and she was definitely one of the top few people I'd worked with, so I was more than happy to say yes.

Most of the questions were straightforward and easy to answer. However, one of the potential questions seemed way off-base: I may be asked to "review her multi-tasking ability."

Is that a trick question? Is it relevant? More...

A great development team is an asset that gains you competitive advantage in the marketplace. They churn out features quicker than other teams, with higher quality code that contains fewer defects. You give them project after project and they routinely meet or exceed the deadline.

They're well known for hitting on all cylinders often enough to pull off seemingly miraculous feats of software engineering. More...

Many people see spectacular plays from athletes and think that the great ones are the ones making those plays.

I have another theory: It's the lesser players who make the "great" plays, because thier ability doesn't take them far enough to make it look easy. On top of it all, you could say guys who make fewers mistakes just aren't fast enough to have been in a position to make the play at all.


The other day on twitter I asked about large projects, and I wanted to bring the question to the larger audience here.

'Large project' is often used without saying what it means. What does it mean to you? What do you think it means to others?

We hear vague descriptions about project size tossed about all the time: Ruby on Rails is better for small projects. Java is for large projects. Skip the framework for small projects, but I recommend using one for large projects. More...

Everyone will run into "that guy" on a project at some point in their lifetime. He complains about everything, and he's actively trying to subvert it at any given time. It seems like he had an agreement with another vendor to take a kickback, but they didn't win the bid so he's stuck with you until he can prove your incompetence to the other stakeholders in his organization.

At every turn, he's complaining about something. He's "spent hours on the phone" with you about a problem, but you know you've only talked to him once for 5 minutes to get a password outside the normal meetings. The normal meetings resulted in changing requirements and specifications as time went on, and he never spoke up until that part of the product was complete. Now he says you're useless and can't follow directions: he wants the original widget design back.

He's not the only stakeholder, but he's the stakeholder for certain parts of the project. Maybe his mini-projects are just there to grease the wheels and facilitate other parts of the whole. Maybe it's a key part of the end product.

There's an effective way to deal with bitchy subversives when you're at the meeting with everyone from each side of each organization and "that guy" is making insane requests and ridiculous accusations. Simply pose an open question for everyone to answer: what about that piece is holding the rest of the project back?

Trying to answer that question will reveal that there's nothing technical that's holding it back. The only thing holding back the project is that guy's whining.

Then you can move forward.


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