The Dirty Truth Behind Software Development

One of the blogs that I enjoy reading the most is HitCoffee, partly because it is very well written by a fellow geek, but mostly because I can get several topics sparked by just one of the posts there. A recent post about the tango that developers, QA and project managers dance, made me think about what I have learned about software development during my career and I commented…

Every programmer that I have met thinks that they are awesome software designers, however I would venture to say that only about 10% are truly good at it.

Will replied…

Software developers have an amazing capacity for arrogance in general. They really seem to believe that everything would be better if they were running the company. I’ve met MBAs with more humility than a lot of programmers… and I’m thinking of some programmers around here that I really like!

I wrote my first line of code when I was about nine years old. Now it is probably pretty common that a kid that young will customize their myspace or even write a full html page, but back then it was not that common. I was lucky that I went to a school that had IBM clones that we were taught how to use. One of the surprising things about the U.S. education system to me was that even though they had the resources, the computer classes I took here were actually way behind from what I learned in Colombia at a high school level. I will some day write more about that disparity, but I just wanted to give myself some credibility here, when it comes to computers and writing code, I have been around it for quite some time.

We all think of doctors and lawyers as the ultimate arrogant professions, and while some of them probably are, a lot of people in the IT field have a god complex. I have met several programmers that like to use the term programming god. Some of them truly think of themselves as better than others simply because they can read computer code, or have memorized every single intricacy and function of a programming language.

I have no idea why I was spared that faith of becoming arrogant about programming. I do think I am above average when it comes to programming and I am also excellent at bug tracking and solving. That does not make me a better person, just someone that has patience and good logic. I however respect people in other professions inside and outside of my field.

The challenge that companies face is that communication breaks down as soon as their departments stop talking to one another. I was hired at one company because I could potentially bridge a broken relationship between marketing and development, and while I was able to facilitate the running of the projects I was involved in the relationship never seemed to get better. You had web developers trying to be designers and vice versa.

The good software architects that I have met were actually poor programmers. Big picture people tend to either forget about the details or the users. Teams of people seem to make this issue less painful, but all parties need to be truly involved and willing to comprimise.

I learned early in my career that the more I simplified the software I wrote, the more people like the features I implemented. Color coding things has always been something people respond to because it gives them another way to memorize things. I also try to apply a the little principle that computers are better at remembering things, but humans are still superior at make decisions. When I have to leave something up to the user I balance it on that scale.

Almost every programmer that has been in a company for a while thinks they understand the business side of things. However, the business side of any company is a living entity that constantly changes, the bigger the company the bigger the changes. Users are very clever and will use features in ways that they were not intended… do developers then adapt them to do the right thing or remove them?

That is when I think some of the disconnect happens. In situations like this it should be a consensus between the development team and the business that ultimately dictates the direction. Most of the times it is only one of the sides that dictates the direction and that leads in the best scenario to friction and in the worst it least to lost company productivity.

Software development is a lot of times like single life, you date different companies and try to do your best for a while but eventually you want to move on. You feel like you have so much to offer, but you are not appreciated, listened to and could do so much better. The good relations come when you have commitment and truly want to marry a company, truly start to think about what would be best for the company and not what is going to make you seem smart and clever. A programmer can be revered as a genius, but if the software they write is not usable or does not solve the problem it the end its a failure.

13 comments on “The Dirty Truth Behind Software Development

  1. Good thoughts here Logtar. I recall a situation where you and Mark L worked on a project here and your quote, “The challenge that companies face is that communication breaks down as soon as their departments stop talking to one another” was in full effect. The people you guys were trying to develop for refused to give you necessary information for no good reason other than “it should be a black box”. Well, I had that exact same experience yesterday with the same people. I was told to help out W and T with a form they needed. I was shown an example of how it was being used and instantly I thought “that looks like crap, I can do better!!” Despite this, W told me repeatedly to do it the “ugly” way because that is what the users expected and to change it at all would screw everyone up. My issues with this were 1) He made it sound like the users were way too stupid to comprehend anything different than what they had 2) He refused to even pursue something that might be better or even easier for the users because it would involve change 3) He told me that the “development team” decided it should be that way. And I thought, “aren’t I a part of the development team??” Basically I was told to do it this way, whether you like it or not, whether it is right or wrong and we don’t care what you think. I may have had a little bit of that “programmers pride” you were talking about but that kind of cut me down a notch.

  2. I know exactly what you’re talking about. I think it can be as simple as saying that some people are just better at different things than others. We had developers moving into design & it just didnt work well and we had designers get in to ‘fix’ stuff that resulted in a lost weekend for several developers.

    Our company’s problem always seemed to stem from developers mistakingly thinking that they are industry experts. Ouch.

    Good post

  3. Ah, Logtar my friend, you are wise beyond your years. This is a subject near and dear to my heart. Mark and Lucas’ comments are also spot on.

    As a Systems Analyst with 20+ years in the business, I’ve made a few observations. The “programmer arrogance” you describe is quite real. As is the willfull, almost joyfull embrace of technological ignorance by the business folks who pay the bills.

    They don’t want to know how the sausage is made. Just make it taste “like this”.

    I have found that some of the very best programmers are very detail oriented and very literal. The “thing” is this or it’s that. The answer is yes or no. The switch is on or its off. They are binary people. Thats what makes them so good at talking to machines.

    The business people tend to be “fuzzy” people. Everything is nuanced. Everything is a shade of gray.

    This is why business folk and technical folk don’t communicate very well. They speak different languages.

    That is where people like me come in. My job is to take the unicorn and rainbow dreams and wishes of business folk, and translate them into the switch position functionality and requirements that the technical folk can actually use to code.

    I know this is a long comment, but a quick story before I go.

    There was a bank whose first foray into the online world was to automate a loan application.

    A brilliant programmer said “I can do that. That’s easy! Just give me a copy of the form and turn me loose”.

    Which they did.

    Some time later, the programmer proudly unveiled his automated loan application.

    The very first question on the form, before even asking for the customer’s name, address, employment, etc. was this:

    “Have you ever declared bankruptcy?”

    From the programmer’s “logical” perspective, this was the most efficient path. If the answer was “Yes”, no further information needed to be collected or stored. End of loop.

    But from a business perspective…absolute crap.

    The business folk may not always know what they want. But programmers (without guidance) often give the customer exactly what they ask for instead of what they need.

    OK, I’m done.

  4. ANother great post L-man!

    I am not a code monkey, but can say that arrogance is not restricted to programming types. In a big enough company you have one or two from every technical department that gave them a bad rep to the rest of the company.

    People close of their minds about something, and then withdraw from meaningful communication on the topic. This makes the project many times more difficult, and many times less likely to satisfy anybody involved.

  5. Like XO, I have always leaned more towards the analyst and integration role than just a plain developer… mostly because most of the “true” developers I met I did not like. They had almost swallowed some weird cool aid that separated them from all the other mortals… I know one of them that literally did not speak to anyone unless they were technically capable of talking at a “higher” level. And XO, long comments ROCK!

  6. Mark,
  7. What you are talking about was one of the reasons that I hate the term black box. While in big development shops it is necessary for people to be able to compartmentalize development and just worry about the links, it is almost impossible to do in smaller shops where nobody is responsible for cohesiveness. I don’t get why our industry started falling in love with a term that is used to described the only thing recoverable from a tragedy.

  8. I agree there. I a LARGE corporate environment where the IT resources are very segmented, you have a need to use a “black box” model perhaps. I need you to provide me with these inputs and get this type of output, how you do that is your “black box”. But how many people do you know work in a modular environment like that??? None that I’ve ever met, even in big companies.

  9. I absolutely love the attitude I see here that a consensus needs to be reached between the developers and the business. When I order a hamburger, I don’t need the cook to tell me whether I want onions. The consensus should be that a set of clear, complete specifications should be provided, and feature-creep and moving-target syndrome should be avoided as much as possible. If I already have a visual design for a form and need the back-end to process the input in such-and-such way, just make the damned back end, then pat yourself on the back about how awesome you are.

  10. Good analogy there Burrowowl. Not only should the cook not tell you if you want onions or not, but the customer should not tell the cook what temperature to set the grill at. =)

    In my experience, the business people get involved in details that really shouldn’t. If they need xyz data displayed, they shouldn’t be telling me how to write the SQL statement to pull it.

    If companies could actually execute what you said, “The consensus should be that a set of clear, complete specifications should be provided, and feature-creep and moving-target syndrome should be avoided as much as possible.”, then that would be almost the whole battle!! I don’t think I’ve actually seen a complete spec in my life. But that is more managements fault I think because when the spec is written and the application is delivered, the spec writers always come back and say, well of course I need this, this and this too! Duh! How did you not know that, dumb IT people! =)

  11. Mark, et al – Regarding the Black Box scenario…I often get pushback from IT when I provide them with TOO MUCH detail. They tell me “you just need to tell us WHAT you want done. Determining HOW to do it is our job.

  12. Development is made so much easier when developers have something in common with their customers. I’ve heard some developers brag about products they’ve created when they knew nothing about the subject matter on which the product applies. They don’t realize that what they are saying makes them look dumb. Their products most likely turned out like absolute crap with respect to usability.

    The good developers try to really get in touch with their customers. In larger companies there is often a disconnect between developers and customers. I understand that customers shouldn’t necessarily be able to directly contact the developers—productivity would be lost, and there is definitely value in having someone in the middle to manage tasks. On the other hand, I strongly believe that developers should be able to get in touch with customers very easily. They need to see exactly how the customer works, what is expected, why such-and-such interface makes sense, and really get a sense of how the end product will be used. Only then can the developer go and truly build something great…

  13. Mike – I like to bring the developers into the requirements proces as early as possible as team members and collaborators. However, in the very early stages, the developers often don’t want to be bothered sitting in meetings with people who “don’t know what they want”. I find that I produce MUCH better requirements when the develpers have been part of the process. They have a much clearer understanding of what the customer needs if they have been active participants.

    But you are correct that there needs to be “someone in the middle” like a Systems Analyst or a Project Manager to facilitate clear communication and to buffer the B.S.

  14. The programmers and IT “specialists” I’ve come in contact with were very cocky, I’m in the Art Dept so my stereo type came into play just as much as the IT dept. Most lack social skills on the most basic level and have large amounts of inferiority complex masked in the guise of DOS. However, once you actually get them out of their environment and have a non-business conversation they tend to lighten up and move beyond “I know more than you” tude. I think that probably happens in most fields, not just programming & art & business.

    BTW : Artists stereotype is : We know what looks cool, we like Siouxsie & the Banshee’s as well as having an extensive collection of The Smiths & Bauhaus. We like Helvetica & can’t stand PC’s. Porn is Art as long as it’s in Black & White or Sepia Tone.

  15. Excellent point, Logtar, about architects. They are horrible programmers in general. They might not have been at one time, but its been years since I wrote a line of code.

    Programming is expensive in both time and money. I try to look for solutions where programming is needed as little as possible. Solutions like that are infinitely more expensive in the short term but are quicker to implement and shorter in the long term in general.

    There just aren’t enough Logtars around.

Leave a Reply

Your email address will not be published. Required fields are marked *