The Hacker Ethic – Harming Developers?

On Monday Neil McAllister posed the question “is the hacker ethic harming American developers?” Slashdot picked it up and Tim forwarded it to the Radar list. As you might expect, it resulted in some spirited discussion.

James Turner kicked things off with this response (it has been slightly edited from its email form). After James lays out his argument I’ll reply with my thoughts. Then we hope to hear from you. Let us know what you think.

I’ve worked in a lot of organizations that thought that the kind of rigid deforesting paradigms that Nayar is referring to were the magic bullet to keeping all three of the variable (dollars, time, features) under control. Without exception, all they did was get in the way and reduce the productivity of the most senior people to the level of the most junior. All of them exhibited some degree of failure, some catastrophic.

The India shops *love* methodologies like UML and the like, specifically because the problems have been reduced to a simplistic enough granularity that they can be doled out to junior-level staff, who may have only been onboard a few weeks because of the massive churn over there.

At least 3 times at 3 different companies, I’ve seen major pieces of work brought back in-house because the Bangalore team had fallen so far behind or proved so unable to get beyond the literal description of work that they were endangering the project. When you combine the time difference with a tendency to halt dead in their tracks as soon as they hit a stumbling block, it can be a recipe for disaster.

There are certainly some good Indian shops, and I know some outstanding Indian developers (most of whom have come to the States.) But I find Nayar’s comments hilarious. It’s akin to someone saying that American football players aren’t employable in Jamaica because they aren’t able to limbo well. Look at the most successful Web 2.0 companies today, most of them started as garage enterprises with a few talented developers, not a 60 person team of UML jockies following some Arthur Anderson project management program. Heck, look at Google Labs.

In huge projects, you obviously need some master planning and coordination to make sure the tracks meet at the right place to drive in the spike, but I don’t see any effort being made these days to right-size the amount of project overhead to the needs of the projects. Instead we get a one-size-fits-all approach that smothers anything but the largest project in paperwork. Even some of the original authors of the Agile manifesto, when I’ve talked to them, point out that part of being Agile is picking and choosing the right components of project management that make sense for a given task.

Nayar’s remarks are incredibly self-serving. “We’re the best, because we can mindlessly follow some arbitrary and flawed development process.” Or is he claiming that Indian projects do better QA? Not in my experience…

This entire debacle is representative of a problem I think is endemic in the industry these days, the inability or unwillingness to engage in rapid prototyping. Every successful project I’ve ever worked on (and I’ve worked on some fairly large enterprise-sized projects), we started by designing and coding a quick “throw-away” skeleton of the application, that let us look at how the thing worked, where the unseen warts were, and where the vendors had lied about their APIs, etc. This is the crucial and neglected stage in project design, one that most modern design paradigms ignore or actively discourage. Even Agile tries to jump in and start coding the finished application from the get go, although if project teams were willing to aggressively refactor (a tenant of Agile), early project work could be a rapid prototype (although the story model of scrum really doesn’t fit well with this, unless you make the prototype a story…)

This is also something I’ve never seen an offshored team do particularly well…

Well, I’ll be damned if I’m going to jump in and take the side that says hacking is bad for American programmers. First off, I don’t need that kind of flame bait and second, I don’t believe it. I think approachable programming is hugely important because that’s how many people get into the field in the first place. However, my reaction to the article was very different than James’ and I might as well try to explain.

I’m not going to take an opposing position, but it’s not really an orthogonal position either. Maybe it has a power factor of about .7 or so. Here’s my (also edited) response…

When I when I read McAllister’s piece, at least some of it resonated with me. Before we were bought by a large firm, we were a small company that grew from nothing to 250 people, about 200 or more of them were programmers. So, a whole lot of my time over three years was spent hiring programmers and building cohesive teams that could deliver to our customers.

In our hiring we aggressively hired hackers into the mix. We wanted outside-our-industry thinking and we thought they brought in creativity. We called it “hiring weird, but not weird weird.” Occasionally we pushed it to weird and a half. For our efforts we got creative problem solving and interesting (but frequently weird) dinnertime conversation when we travelled.

However, our pollyanna idea of “disciplined teams catalyzed with a bit of weird” didn’t always work out.

That leads to the bit that resonated with me: the sense that hacker = distilled essence of American individualism combined with lots of ISTJ Myer’s Brigg’s Type Indicator. Individualism is a trait that I hold dearly, but it can make a cohesive team effort difficult if people are unwilling to suborn themselves to the goals of the team. Remember those tee shirts the football team always wore at your university? “There is no I in team?” I sometimes joked that I was going to make a batch that said “I’m the Me in team.”

Maybe we were just growing fast and it was going to take more storming and norming than I had patience for, but at times it was a struggle to get everyone to see past their individual biases and focus on what we were trying to achieve, and we couldn’t do what we were trying to do with teams of one.

But it really wasn’t a hacker problem if hacker means self taught like McAllister implies. We had a lot of people with CS degrees and we used to talk a lot about whether and how their degrees had prepared them for their jobs.

Separate from the individualist approach to development, few of our recent graduates came to us prepared with the terminology and practices of any development approach (or engineering approaches like continuous integration etc.). They knew how to code, but not how teams coded.

At one point I gave a talk on agile software development to about 100 CS students at a university in Philadelphia and I asked them to raise their hands if they had ever done a team project with greater than two people on the team. I don’t recall anyone raising a hand. Then I asked if they had ever covered development methodologies in their classes and a few acknowledged they had, but it had been abstract classroom stuff only. That part surprised me.

I’m not sure that the “sanctity of engineering” argument really makes that much difference. I have little faith in McAllister’s scheme to do computer engineering instead of computer science coursework.

My undergraduate degree was in Mechanical Engineering and I can only imagine how useless I would have been to a firm that actually did engineering, and for mostly the same reasons. I knew how to take integrals and I still know the packing ratio of a hexagonal close packed material but I didn’t know squat about how a complex machine actually got designed in a team setting. It’s interesting to note that the Engineer in Training exam I took (a precursor to the professional engineer’s exam) didn’t probe my knowledge of team practices at all.

Maybe there just isn’t time in an undergraduate degree to teach everything that an engineer needs to know. Plus, can you imagine the drop out rate in CS/CE if ITIL was a required course?

Since James mentioned Google I’ll switch gears and muse about ecosystems for a moment… I guess I tend to bristle when I hear that everyone should just develop software the way Google does.

Google is to computing what LA was to Aerospace and Electronics in the early 60’s. It’s gravitational force attracts five sigma talent (probably a bunch of six too) in ways that the rest of us can only envy. More generally, Silicon Valley has had programmer talent flowing into it for the last twenty years the way Hollywood sucks pretty people out of the midwest.

Maybe it’s not as obvious because you can’t spot brains the way you can spot an oddly beautiful wait staff, but the valley has been the vortex of a talent-laden embarrassment of riches for a long time and, if you work there, you might not even notice it. However, I think that at some level this effects what kinds of processes work when you build software. I think it’s at least a little part of the reason why an ERP system in a manufacturing town gets implemented differently than MapReduce (there are other reasons too having to do with software as product vs software as supporting infrastructure). Combine that with the very clear shared vision of “lets do something great and get rich together” thing that valley firms often have, and well, it’s easy to see how smart people coalesce to build amazing stuff.

It’s easy to denigrate Arthur Anderson’s progeny or the offshore firms they compete with, but they do different work, with a different talent pool, for different ends, and with a very different set of personal and organizational incentives. Or, put another way, Kelly Johnson didn’t build the SR-71 with General Motor’s engineers, and General Motors didn’t design the Chevy Cavalier with the Skunkworks’ processes. However, even at the Skunkworks, Johnson’s brilliant engineers did conform to a process and work together as a team toward a shared vision. And, conversely, I bet a lot of talent is left on the table at General Motors because of processes too restrictive in their attempt to remove all uncertainty.

So,… maybe it’s possible that Google’s (or the valley’s in general) processes are appropriate to an ecosystem that, because of the intellectual environment and potential for riches, is rich in IQ and initiative. So it ends up feeling more “special forces” and less like “infantry regiment.” And over there closer to the hump in the normal distribution curve, or in a different cultural environment outside of the valley, a different flavor of processes may be effective?

The counter argument to that, which I’ll go ahead and provide, is that I once helped teach a team of engineers at midwestern defense contractor how to do agile development. The effect was amazing and immediate and their productivity and satisfaction went up tremendously; until their management freaked out and shut it down when they “perceived” that it created too much uncertainty in their processes.

Well, it’s obvious that I don’t know the answers here, so, with that, I’ll stop thinking out loud.

What do you think?

  • Tom

    Having done several rounds of new grad hiring in the past couple years, I would say that the problem is that there aren’t enough self-study CS students. Many of the candidates just don’t seem to do any programming outside of the required course activities. All of the good engineers I know (of all flavors) have always had home projects that weren’t for class credit or salary.
    True, the new grads don’t know how to work on a team. But it’s hard to give students the feel of a 60 person team on a 5 or 10 year project in a 4 month class of 30 students. Most new grads learn the ropes of team development pretty quickly after they start working.

  • I am currently getting my BS in computer science, and I have to agree with Tom. The problem, I think, is the way in which most CS students view programming. There seems to be very few CS students who actually and truly enjoy CS, and a whole lot of them that went into it thinking it would provide them with a good career. A lot of them believe that because they enjoyed working with computers, or were “good” with them growing up, they would also enjoy CS.

  • Agree with comments above, but it really isn’t that simple. There’s a definitive gap in CS programs. And, that gap is Software Engineering. The process, rather than the art or science of programming. Team effectiveness has more to do with how well you can embed into a process than with your ability to solve problems (which is a parallel tendril here).

    I’m not saying a good software engineer implies a good software developer. There is a definite requirement for both sides – especially in enterprise, or commercial development.

    This is such a hugely broad issue. The problems induced by off-shoring, the power of the Open Source world, and the lack of motivated graduates all play. But, there’s no doubt in my mind that the “hacker ethos” has greatly improved the development world. Just look at where the real industry/social innovation is these days: software.

  • Mario Palomera

    Yes!, personal passion plays a very important role. I graduated from CS about one year ago and had the honor and luck to have some great teachers at school. They forced us into working in 5 person teams at least. Each team developed one module then all the teams had to integrate at the last month. I’ve learned a lot about human interaction, lazy people, brilliant people, mediocre ones and of course there has to be a balance. I think the best example of creative team building is Pixar (from HBR article). Their priority is to build teams that work well together and have good social dynamics (respect, motivation..).
    The thing that turns me on to write thousands of lines of code are design patterns, beautiful SW architecture, usable and dynamic interfaces and Frameworks or API’s. Without those I would have given up programming a long time ago. The thrill of creating something new is the best.
    Project management methodologies are useful of course, but they don’t assure quality or get SW done.
    In big projects and specially innovating ones, there are always going to be problems and huge challenges, the key is to have creative and passionate people that are able to overcome those.
    The firms or companies that put up income as their priority usually start messing big time very quickly (no matter what country).
    Very good article by the way.

  • Both comments above make very good points that I agree with. I learned more about programming from the three semester independent study than I did from the rest of my courses combined.

    I’m a part time teacher at a nearby university teaching the second semester algorithms (read: programming) course. To compound Tom’s point, students aren’t being required to do enough programming even within the classes. Some of it is politics, the desire for the courses to appeal to non-CS majors (at the expense of the CS majors’ educations).

    Some of it is that the department as a whole treats Computer Science as a very theoretical major, blowing off suggestions for more real world oriented projects as the realm of Software Engineering (the SE course offered as part of the major is inadequate; it is unacceptable to have a purely academic teaching a course in real world projects). From my understanding, there are professors who argue in favor of even less programming.

    I understand the Computer Science v. Software Engineering distinction. But we also need to be rooted in reality. Very few if any of the graduates are going to go into a theoretical or computational field. Most will walk into programming or sysadmin jobs. And they do so unprepared.

  • Ed

    What happen to “apprenticeship” and “mentoring”?

    I’ve heard a lot of “we’re doing X,Y,Z because of the Junior developer”. Why not teach them how to become a better developer than pushing UML?

    What about “if you’re gone, the next guy should be able to take your work” kind of situation? How could we communicate better? Aren’t we selfish taking the system hostage by not following certain process/standard?

    @Tom: why is it a problem such that CS students must be self-study of their own field?

    I’m sure all of us had been a student one way or the other during our lifetime. Here’s what a student life looks like:
    – Go to classes (skipping classes is like a developer skip QA or writing unit-tests)
    – Outside classes => Study, study, study. Join an organization to learn how to work with other people. Learn something else: language, economics, musics, join a band, etc.

    Why should they self-study of their own field while they knew they would have the whole lifetime to learn it? Aren’t we all in this field for our entire life before we retire?

  • The hacker mindset that is fostered so well here in the US is an absolute advantage but does need to be tamed. As Tom and Andrew pointed out, all of the most talented, skilled and driven folks I know do take their work home with them in the form of hobbyist hacking of one form or another. At the same time, there is a distinct need for engineers of all sorts to be able to function as part of a team and to be successful when working on a piece of a project, not necessarily in the spotlight. The real question raised is not if the hacker ethic hurts or helps because it can do both, the better question is how to effectively manage great talent. And I think that is a question for companies and managers to solve, not schools.

  • bex

    More generally, Silicon Valley has had programmer talent flowing into it for the last twenty years the way Hollywood sucks pretty people out of the midwest.

    Speaking as a hacker from the Midwest, I’d argue that Valley folks have this completely backwards.

    A GOOD developer can find good work in any major city… there is no need to move to find fun, exciting, well paying gigs if you have actual talent. The hackers in the Valley are either good developers lured away with extremely high pay, or LOUSY developers who go there because they can’t hack it elsewhere. Or those with entitlement issues.

    I’d wager the AVERAGE hacker in New York, Chicago, Minneapolis, Atlanta, Portland, and Seattle could code circles around the average hacker in the Valley…

  • @bex – so very true. The experienced hacker, with skills (or skillz) can live anywhere, and web-commute. But, this is a significant data point in this discussion. It has been my experience that good software devers/engineers can be remote and functional. But, many large organizations (with mid-to-large teams) can’t handle these folks. Hackers can work with remote hackers. But, teams can’t work with remote hackers.

    This is another fundamental piece of software engineering that isn’t being taught, or learned – how to work in isolation (self-driven).

    Obviously this is independent of the firms in the Silicon Valley, versus firms in the Midwest. But, that’s a percentage game too, right? I mean Garmin is in Olathe, Kansas. Who else is in the Midwest? And, surely there’s a relationship to the academic funnel of startups.

    I like your wager…I’m with you.

  • Borton

    I’m not sure that “hacker” is really the correct term to use in this discussion since it has taken on such negative connotation in common use. When you throw out that word, people immediately think of the fat underachiever freak in mom’s basement with Mountain Dew and Cheetos, steeling credit card numbers so they can buy porn. It’s true, that kind of person will likely not play well with others, and though they may be creative, will not be able to adhere to any structured development initiative, in the end causing more harm then good.
    I think what we’re really discussing is people with flexible minds. They are creative thinkers who are curious and can be extremely passionate about a topic or project. Generally we’re also talking about extremely intelligent people. As such, learning a development methodology is trivial. While these flexible thinkers can often be individualistic, most will have no problem working with a team. The problem comes in when these people begin to feel constrained by the methodologies. They tend to either rebel and do something counter-productive, or wander off to something more interesting and less binding.
    So what’s the answer? In the military they use the term “economy of force”. Use the personnel in the most effective way possible. If you have flexible thinkers, use them in projects where the rules and the development cycle are flexible. Use conformists (another word with an undue negative connotation,) for situations that require strict adherence to the scripture of ITIL. This puts the onus for project success back on the shoulders of management where it belongs.

  • Among the BRICs, India might be the extreme case where heavy process-oriented development has been used to cushion cultural differences…or maybe that was the way they sold offshore development to large American companies almost a decade ago. I had extensive experience managing teams there and cannot disagree with James Turner.

    It’s also a mistake to put all the BRICs in the same bag. They share the fact of being powerful countries rising and growing fast, but comparisons should stop there. I think I can speak for Brazil because that’s where I came from and where my development team is based now. When I learned Computer Science there 30 years ago I learned the “boring details of tech process, methodology, and tools”. But what we see now is a hacker culture very prevalent and entrepreneurship on the rise.

    I’d like to some point of views on China and how they fit into this discussion.

  • Kumar

    Taking Nayar seriously is a big time waster. Ignore him and get back to coding … oops, I meant hacking :)

  • casey

    There’s definitely some truth in that US developers fresh out of academia lack experience working in a team. This was the case with myself fresh out of school. The problem is, there is little incentive for collaborating on an academic project, given a choice. In industry, you can more easily avoid, reassign or fire under-performing team members. On an academic project, there are exceptions to be sure, but chances are, if you’re good, you’ll likely be stuck with others who are there for a free ride.

    I think you can only find similarly motivated individuals when there are well established responsibilities and rewards in place, as there tend to be more often in industry. And I think you can only really understand agile (as more than a bag of buzzwords) when you’ve struggled in such an environment.

  • Nick Pilon

    I don’t think the “hacker ethic” harms or helps American developers. I’ve met plenty of hackers who produce wonderfully-maintainable code, meet launch dates, address customer needs, etc. and plenty of formal, rigorous software engineers who don’t. I think the problem is modern American Computer Science education. As you noted, most CS students never spend long amounts of time working with a large team. Not only that, but their projects – even when doing research! – are invariably throw-away one-offs. I know that none of the classes I took required that I to learn to maintain a large, living piece of software, deal with changing requirements, etc.

    This is hardly the only problem with modern CS education. I’d say that many of the things McAllister identifies as problems with US college graduates are, indeed, problems with US college graduates. The program I went through – and the experiences I’ve had related to me by others make me think I’m not alone – was practically purposefully crafted to encourage these “quirks”. No understanding of a broad range of development tools? How are students expected to learn a broad range of development tools they’re forbidden to use? I’ve seen professors ban Eclipse, of all things, in a Java programming course because they’re afraid their students will “learn the tool, not the language”. (Actual reason: Eclipse’s excellent contextual help means that they can’t base an assignment’s challenge on hunting through inadequate documentation or puzzling out arcane compiler warnings.)

    This obsession with doing things the hard way and disdain for tools extends well beyond IDEs. Version control, language choice (IE: an almost-fetishistic obsession with C++), forbidding or discouraging group work…

    I certainly know that I’ve learned more useful skills outside of my formal CS education than I did within it, and more harmful habits within it than outside it.

  • A couple more points, raised in discussion about this subject with a peer:

    * Industry interview processes – especially the differences between SMBs and large organizations, as well as the attributes of product versus services companies.

    * Internships – and the role they need to play in the development of young engineers.

    @Nick – your point about Eclipse is very poignant. Software engineering these days is as much about frameworks and tools as it is about writing code. I think there are many good examples of how industry educates itself (JavaOne, NoFluffJustStuff, camps, and vertical seminars, etc.). Wondering if it would make sense to make these kinds of things (more formal than just user groups) accessible to students and green engineers.

    Lastly, it isn’t always about knowledge, skills or abilities as an engineer. Sometimes it is just awareness, and the ability to get started.

  • Tom (Hagerstown, MD)

    I feel that while book smarts are good for the average code-monkey, you still need to have a few of your OWN coding projects under your belt to really excel in this field.

    Having most of my knowledge being self-taught, it has taken me the better part of 20 years to really get a go at software/web development.

    So while I do think that kids just coming out of college might have the right papers to get a good paying job in the coding industry, you still need to have a bit of self-taught, self-motivated coding under your belt. And I’m not talking about some cookie-cutter html and the like. I talking about actually getting down to the code level and creating on the fly.

    So get out there and code something that you’ll use. You never know, that personal project might be what you need to succeed!

  • @Ed, it’s not a case of whether CS “should” be learning new things at home via side projects, it is that the people who are best suited to this career “do” because that’s what they enjoy.

    If somebody doesn’t enjoy programming enough to do it in their spare time for fun then perhaps they shouldn’t get a programming job. I’ve always held to the principle that if at all possible people should get jobs which they enjoy.

  • I’ve been hacking since the age of 8. Recently, I attended college to learn development processes. It’s fascinating work.

    Also, I think I’d rather be a System’s Analyst rather than a Junior Programmer after taking college for a year.

    After college – I am going to university to get a CS degree. Then look for work. Not in the Valley – but in Great Britain.

    Personally, as a original hacker of the 80’s – I find having structure to a program development process really helpful. I even start designing software for one day before writing it now! Haha.

    People can change!

  • Andy R.


    The passion element is nothing new. I took my BSCS in 1983, and even then it was clear that the substantial motivating factor was money/career, rather than passion.

    Some of the best software developers I have ever worked with have been non-degree, self-taught and passionate. And many of the worst have been MS and PhD degree holders.

  • Paolo

    Hacker Ethics my a**
    Do you want to see how real world engineering is done? Go to Intel. Guess what, Intel company’s culture puts simple yet effective project management techniques at its engineering process’s heart. If you don’t learn project management techniques, you are not going to be working at Intel for long …

    I am not advocating process over creativity (you need both), I am advocating managing engineering creativity so that things get done, instead of throwing s**t at the wall till something sticks.
    Again, go visit Intel.
    Now, I personally would never work for Intel because of other company culture aspects I don’t like at all (big brother watching you), but if I wanted to be part of a well working engineering environment were creativity is channeled into business processes at almost its best, then that’s where I’d would want to be working.

    What Mr. Nayar meant to say is that US grads are not willing to humble in their approach to the engineering profession … or any profession for that matter.

    It has nothing to do with creativity or engineering skills.

    Besides, it serves very little to be “agiling”, if there is no underlying engineering process. The result will be a pile of sh**t anyway, no matter how much smart hacking you do.

  • @paolo – isn’t Intel also infamous for the “analysis paralysis” term? :)

    Here’s a timely link:

  • Sharath Shetty

    I am Indian… Aaaggghhhh! Yes, and when I read Vineeth Nayar’s statement, I couldn’t stop laughing. This is a clear case of pot calling the kettle black. Also, he was not making an original statement either. This particular statement has been made within the Indian software industry by many industry leaders in the past few years, about Indian graduates.

    The following news item from 2006 comes from the most celebrated Indian Software leader namely Narayana Murthy, and not some obscure Vineet Nayar. I had never heard of Mr.Nayar before this news item.

    Here is one more from 2008.

    This one is India Labour Report 2007, search for the term unemployable and you will be amazed.

    Therefore, please don’t take Mr.Vineet Nayar too seriously. He could be right about the quality of American graduates, but that does not mean Indian graduates are any better. In fact, I know it is not better. I run a software product company in India, and I can see that most of Indian engineering graduates are indeed unemployable. And I can shed some light on that.

    I studied Electronics Engineering in Bangalore in the 80s, which only taught me the hardware side of computers. During that time, I was accidently dragged into a C programming class taught by a hacker. And he made me fall in love with programming. Soon I taught myself 8086 assembly and C++ and got into software industry. Fortunately I got into an anti-virus company which was also trying to develop a Norton Utilities clone, and I worked a lot on that. By the time I left that company I guess I had turned into a hacker. For example, even while using C++ I did all disk I/O with INT 13/21 and all screen I/O by writing into video buffer, etc. I could create tools at the drop of a hat, and would automate anything I needed to repeat.

    However, my next job was with one of the largest consulting companies, the kind of company Vineet Nayar represents. Here all the real work of coding and designing was done by juniors (5 years or below) and everybody else did project management, process management, quality management, etc. Cutting edge technology was disdained, even discouraged. Everybody worked on mature technologies where there was no uncertainty. In other words, COBOL, Mainframes and waterfall methodology. At first they didn’t know what to do with a C++/C/ASM developer who would delete the partition table every evening as security measure. Well, DOS/Windows didn’t have secure login then. This was the trouble I caused by being a hacker in a process driven company.

    Almost all medium to large Indian companies are process driven. They hire the cream or top students from all the reputed colleges and take them through rigorous cookie cutter training process and create a hoard of process oriented engineers who can do a given job with predictable competence. Conformance is the mantra, and not creativity. Therefore it was difficult for them to fit me into any category other than a troubleshooter/explorer-of-new-technology. After kicking me around for a year, they deputed me to AT&T Bell Labs in NJ where I could work with like-minded people. And this was 16 years back. Now that I run a company in India, I see that nothing has really changed. The colleges still churn out mostly unemployable graduates unmindful of industry requirement. The industry still hires the best of them and takes them through cookie cutter training process where they numb the grads into drones. Consider this, all the employable grads are mostly picked up by top companies and turned into drones. And they do this even with the unemployable grads.

    Being a product company we want creative people, and we can’t get them because all the employable/creative/proactive guys are swept away by top companies, only to feed them to cookie cutter process. The success rate of getting through my company hiring process is less than 1% now. And that is not because the screening is tough, it is in fact pretty easy. But it is geared differently in order to get creative engineers. We look for fresh grads who still have some creative spirit left in them, but I regret to say our colleges in India make a thorough job of stripping away every ounce of creativity.

  • Roman

    The original article and the reply voice opinions on a rather opposite end of a spectre. The comment above about “hackers who have to be tamed” puts it best for me. Heavy reliance on process is absolutely defensless against constantly changing requirements and “need it yesterday” deadline, which is quite common in the corporate world (well, at least in finance which i can speak of.) In such situations creative thinking, adaptability to the situation at hand, quick learning of the working of the business sector for which the product is being developed, and the ability to produce code which works! reasonably well very fast come to light. This is pretty much definition of a hacker. Constantly rewriting UML or even unit tests could easily be counter-productive considering that the delay it introduces might mean a missed business opportunity. Of course, there’s some planning to be had in the beginning and as the project progresses, but it is mostly “play by ear.” This strategy has it’s draw backs – there’s almost always a need for a version two, but V2 is to be developed for an existing business which means much more relaxed deadline and budget. During V2 implementing a good developement process is necessary, but it becomes cost-effective because developers are familiar with the business, users have a general idea of what they need, and the time being spent on the process is manageable.

  • Stan

    Interesting article and interesting responses. If I looked back to the 1980’s, I would find some of the same articles and opinions. The technologies would be different, but the problems are the same.

    Every hack I have run into has the same thing in common with the next hack: they have passion. If you are in the IT business, you need that to get through the low times. If you are in the pizza business, you need passion for that also.

    Speaking from a small shop view, I do not really expect any graduate to go at the level of an 8 year programmer, analyst or “pick your own title.” I do expect them to listen and learn once, then add some of their intelligence to the work. I would also expect them to stay with me for some period of time if I invest dollars and my time in some real knowledge and training. I do not expect them to learn and leave.

    The most interesting thing that I find about these comments is that, not once, has the interests of the business that hired anyone been considered. It seems the major mission here is to land the big one, bill it out until the client can’t pay anymore, then go to the next gig. Business is interested in purchasing IT services, but only when those services will enhance their business.

    Oddly enough, that is why people call me. I talk to them about their business first, then how the IT processes and services can help their business. I have a meeting next week with a director that I met walking out of my building to the car. Why? I told him what I did and how I help them with back end processes, then tied it to specific things about his business. I did not mention a compiler one time. My point: most programmers I run into don’t have a care about what their code will be used for. Some do, and those are the people I want to talk to. It is the first thing I look for in an interview.

    It sounds like people are loosing track of the mission. Software is supposed to help a business become more profitable in some way. I see the comment about significant re-writing UML? That is an Agile red flag. That means you missed something previously in your process.

    Really good software requires really good creativity. Maybe the arguement should be creativity = hacker? I would submit that any good programmer has got some level of hacker in them, and I think that is a good thing. You can’t keep replicating the same code everwhere due to copyright infringement. Furthermore, why keep copying the code when you can improve it!

    I always thought the idea was to improved the art. I always thought that we learned something new every day, so I consider my self a newbie at 20 years of experience.

  • Steve Naidamast

    I am not sure if I agree with anyone on this post… and I read Neil McAllister’s article as well.

    I have been in the IT field for 35 years and in general I have seen an overall deterioration of individual skills since the beginning of the distributed computing era. First and foremost, in the mainframe world there may not have been a lot of leeway as to how things were done but at the same time there was far more discipline and greater expectations that people knew how to develop systems properly.

    In the distributed environments I have found that good American technicians have practically always exceeded their Indian and Chinese counterparts while only our Russian and South American colleagues showed similar expertise.

    However, on a general basis, those that claim that many American CS people are just in it for the money are mostly correct. Little passion is shown currently for doing quality development work while long term goals are always on management. However, one also finds superior technical articles written by American software engineers along with more competent software offerings that are only equaled by our European friends.

    One wonders how one can manage a technical team if they are not proficient at development and systems analysis. God help us if aeronautical engineers worked in the same way; the planes would be falling out of the sky.

    Indian technicians specifically have been the biggest disappointment over the years and their managers are by far the worst one can come in contact with. Initially, many Indian colleagues I worked with were bright, highly competent, and some of the nicest people you would ever want to work with. However, as outsourcing gained in momentum these traits drastically changed.

    Yes, Indian technicians are still well trained in technology but they have little idea as to how to apply it to systems development. They are now people filled to the brim with technical details but little understanding in the “arts” that are the foundations of good system design. While they are quite capable of implementing systems that work, the levels of complexity they bring to their work as a result of their knowledge drives maintenance costs through the roof.

    This in turn has led to an entire cadre of new Indian technical managers that are supremely arrogant in their views towards their American contemporaries of whom they expect to work at inhuman paces to keep up with their own expectations coming from their technical “detailitis” (a serious engineering symptom).

    To a person American technicians have made the same complaint about their own Indian managers to the point that many have no intent of working for them in the future. If this happens, IT for a while may appear to be only a place dominated by Indian personnel, and in many ways it is that way already. However, overall quality in output will seriously erode even further than it already has. However, if the work is still made inexpensive, the Six-Sigma boys will keep on hiring them until the companies collapse all-together.

    Does this make American technical managers better? Absolutely not despite the softer approaches, they are highly politicized and have far less technical know-how than their Indian counterparts.

    In terms of how all this plays out in the technical environments, the results are all there for everyone to see. The average project failure rates are still at a hovering high of 70%. This hasn’t changed in 30 years. So whatever foreign technicians are bringing to the table it hasn’t improved project success by any noticeable factor.

    The inclusion of such system design principals as XP (In fact, XP is completely based upon a failed paradigm.) and Agile are more an offshoot of pressures by incompetent managers designing incomprehensible deadlines than any innovation in systems development. Both such paradigms, along with their lesser known siblings, are complete rubbish.

    There is only one way to design good systems and this includes thoughtful design, good prototyping and disciplined development with capable personnel… not people who can recite textbook details and produce code at lightening fast rates but implemented by those who still take into consideration the basic art-form of writing good, legible but most importantly, simplistic and easy to maintain code.

    The constant touting of coding to performance issues is an illusory habit of our Indian colleagues that is used to basically put down subordinates (which I understand is a foremost trait of most Indian managers.) that has little legitimacy in systems development. The simple reason why is that as one highly competent Indian internals specialist, a friend of mine, who constantly regaled against his own contemporaries for such blatant stupidity, often claimed is that with modern compilers there is little that can be accomplished to make things run faster no matter how you code. In order to effect the outcome of such compilers one would have to literally write highly egregious code to get some results.

    In reference to the Indian CEO who lauded the learning of Six-Sigma by Indian technical personnel in training, like ,most such people in “leadership” positions, “he ain’t there because of his brains…”…

    Six-Sigma is a financial analysis tool which is only good when combined with the CMMI modeling processes. In recent research and reporting it has been found that those companies that merely incorporated Six-Sigma alone, it has been noted that over time general corporate creativity drops substantially leaving the company with mediocre product generation, GE surprisingly being one of the noted companies in the study. Though such companies are very efficient financially, it has been found that most of these companies have only that as any claim to fame in the business world.

    The innovation in IT will always come from those professional developers and technicians that find a more elegant way to accomplish a task. Most of the innovation we are seeing today from vendor companies are basically redundant ways of doing things with little more than a pretty veneer to offer developers along with a whole lot of headaches in having to add yet another technology possibility to our tool-belts. Microsoft’s LINQ is a classic example and is also the reason why it is being silently jettisoned.

    In terms of IT management, little has changed in their attitudes and capabilities over the years. They are not people I would want to find in the same fox-hole with me, given their levels of incompetence… but worse, arrogance.

    Except for a single CIO that I worked for (who was excellent) the overall capabilities of IT leadership in general are simply in politics and self aggrandizement like anyone else in the such manager roles. The effect on IT personnel has been quite obvious…

  • Matthew A. Todd

    I’ve seen the same as Andrew (2nd post) in college. Most of the students don’t care and seem to only be taking the major because they like computers or like the salaries programmers are said to get.