"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."
Let's tell it like it really is...
The India shops (and many U.S. shops, too) love methodologies like UML because they make someone who does not know what he is doing appear as if he did.
This is especially important for maintaining margins above 50%.
This is the most recent comment from the article that started this little discussion:
> Hi All,
> I am just another IT Engineer from India working for the one of the largest IT companies in India. And I know that what Indian IT companies like HCL work for, only money (through offshoring). They do not want people who use brain because they don't have such work to do. All they want is a duffer who sits on a desk and can work like a donkey for 12 hours a day. There are no excuses such as work life balance etc, because client is the boss. You can not say no to anything. They fake the resumes of employees, make them achieve impossible target by making them work like a dog. The estimation is the beginning of a big mess to happen. Moreover an IT engineer must be prepared to be fired, because they have a reason of recession. They can handout dividend to shareholders by cutting the variable pays.
> As per what Veenit says is Indian people learn to following processes etc, but when you look inside a IT company, you can rest assured everything can be managed. There is not advantage in following processes, because what I have seen is 90% time of my PL goes in following these processes. The project leader has no time for his team.
> I believe that IT companies like HCL wont take up innovative work at all, so creative minds in US should not bother about his comments. Although lots of work is getting outsourced. The core work is going to remain in countries like US, because most of the people working in huge companies like HCL, Infy, TCS ,Wipro and Satyam become incompetent because of the quality of work they get most of the time.
> Moreover a person wont work on a specific business or technical domain, which leaves makes you loose confidence.
> There are many people like me who once get stuck in such companies, its really hard to come out.
> So Americans, better dont go to such sh companies. Its better for your own future.
As someone who's worked closely with Indian developers for the past 3 years, I can corroborate several of the statements above. My teammates and I were usually spellbound by the acronym-laden resumes of some Indian developers. "Wow, this guy must be really good! Look at his credentials, dude!", I used to say frequently. Reality, however, sinks in rather quickly. More often than not, the "super star" ended up turning in subpar code, working a bazillion hours a week and, still, missing deadlines and estimates by ample marks. It was all very confusing at first. I understand fully now.
I'm not saying there aren't excellent Indian developers. I've also met a few of those. Alas, those are not the majority.
Im too young to know firsthand, but I recall during the .com boom here in the states one of the problems was that anyone who knew how to spell html could get a programming job. It was a hot field and people seeking the "big money" were getting programming jobs they didn't deserve. On the university side I knew several people who switched majors to business when they learned that coding involved typing (no joke). Perhaps the same is going on in India right now? From all accounts, programming is the hot job in India.
I bet if someone put together a good summary of the "brilliant" people in a field, and had them talk about the level of talent when that field is the hot job, it would look the same as these coder stories.
I can say that I've worked with several excellent Indian developers here in the United States, and they regarded Indian firms as (by and large) unsuitable places for competent people to work. They said the prevailing approach was to hire the cheapest possible people, scrupulously go through the motions (cargo-cult style,) produce copious evidence of work, and be sure to meet the project requirements in some literal sense so you get paid. As for quality, as for whether you produced something that the client could actually use, well, that's someone else's concern. If you managed to provide something that resembled the requirements and it isn't usable, that's someone else's fault.
I can sympathize with this from a cultural point of view, because it's frustrating to try to fill in the blanks and detect deficiencies in requirements when you don't have the same cultural context. It's easier to just work to the spec, and naturally (under business pressure) this devolves into working to spec in a very minimal and cynical way.
go through the motions (cargo-cult style,) produce copious evidence of work, and be sure to meet the project requirements in some literal sense so you get paid. As for quality, as for whether you produced something that the client could actually use, well, that's someone else's concern. If you managed to provide something that resembled the requirements and it isn't usable, that's someone else's fault.
On the other hand, these companies get business. They would not get business if their work was unusable. You can sell a crap car for cheap. But you can't sell a car that doesn't drive. And if you can (time + materials, work to specs, etc.), you can't do it twice.
I'm just saying, the market is hard at work here. They must be filling a need.
Do they get repeat business? Also, are American engineers that use their work being pressured to frame the collaboration as a success? When a VP's bonus depends on his ability to show cost savings through offshoring, you can bet the managers under him will find some way to patch up the code stateside and declare the project a success. The official proclamations of success create good word-of-mouth for the contract company, so they get more business. I've seen this happen firsthand, not with offshoring to India, but with developers being forced to work with an American consulting firm that their executive happened to trust more than his own staff.
> They would not get business if their work was unusable.
It happens. A four-man startup I worked at in 2000 tried to outsource some thick client development. Their first deliverable wasn't even close to being compiler ready. It took a couple weeks of conference calls just to get a binary that didn't crash instantly.
A larger employer later had much the same experience. The code we got from a contract shop was such a trainwreck that we opened a branch office and hired our own developers over there instead; that worked out fine.
Well written code is approchable without constructs like UML. The problem with most 'programmers' is that they don't think they should be doing hard programming each day, every day. Yes, experienced hackers make it look easy, but it took them a lot of work to get there.
Also, just because hackers are a scare resource doesn't mean we should accept a lower quality in the end product. What if we did that with the engineers that worked on airplanes? Software is used in many similarly critical situations. It's time to accept that the things that adults use like UML and overly complex IDEs don't increase the number of good programmers. Ironically, they actually mask the true ability of a programmer. To actually accomplish that, you need to start with the programming curriculum in high school and early college education.
Well written code is approchable without constructs like UML.
ANY code is approachable without constructs like UML. Compare the Addison Wesley "Professional Programming" series (the ones that published APUE, UNP, Pthreads books, etc; the white text with a splash of blue) to the yellow/khaki "Object Series", the ones that published Booch's books and the french dude who was pushing Eiffel, etc.) The difference between the two series of books is essentially UML and "object technology". The first is readable bliss, the later is an abomination cast at us from the bowels of hell.
UML is wankery. It's what liars and crooks push when they lack the sufficient bullshit to make it to high executive positions, and the talent, dedication and honesty necessary to be an engineer. Everytime I met a "software architect" that used that garbage, the person was always nearly clueless and a pain to be with.
And should we be amazed at your drawing scribbles, boxes, triangles and whatnot? How should I interpret your abstract and masterful artsy drawing?
There's a time and place for UML. Overdoing is wrong, I agree. But that doesn't mean UML is bad. When a project is huge enough, sometime you do need few pictures to help others to understand the big picture. Some people can understand better via visualization.
I'm not sure if others feel this way, but I'd actually rather see someone's free form artsy drawing than a UML picture. I think it's reasonable to expect that a skilled developer should be able to provide an intuitive whiteboard diagram or slide-show graphic. It takes some practice, sure, but I think UML is the wrong solution. UML is constantly misused. Big enterprises love CASE tools like Rational Rose, which push UML way beyond its intended usefulness.
I'd actually rather see someone's free form artsy drawing than a UML picture
I totally agree. The whole idea behind UML is to force diagrams into a set of constraints drawn from a particular model of computing and design (early 90s OO, I suppose) on the assumption that this is the "right" way to imagine software. This excludes the ineffable creativity which drawings are so good for. It's amazing what happens in a good design discussion when people spontaneously pick up a pen at a whiteboard without thinking about it. UML forces people to think about something other than the problem at hand, distorting ideas and breaking flow.
And in the name of what? "We need a standard," they used to say, "so that people know whether they should draw square boxes or round ones, so we can get beyond the notation wars." What tripe.
Quite right. There's nothing wrong with a dash of UML as seasoning or a visual of some actually critical process, but just like you wouldn't want to eat a half pound of oregano on top of your steak, you don't want to produce as much UML as code.
I have included emitted UML (from running code) into my end documentation (from c#/VS world). But for any work I've ever done, there is a unordered heap of back of envelope artifacts that I fear only make sense to me.
It is hard to capture certain details in prose, and a (nearly zero effort) emitted UML diagram can do the trick. Or at least convincingly make it look like you did the trick...
But start from UML? I think I'd rather spend that time polishing my cv.
"Yes, experienced hackers make it look easy, but it took them a lot of work to get there."
My manager just asked why it took 2 weeks just to promote 1000 lines of code into production.
Today's 1000 lines of code was 5000 lines of code a week ago. I suppose that if I had promoted 5000 lines of code a week ago, I would have looked better. But we know better...
I hear that. At my current job (large defense contractor-- team of 50+ programmers), programmer productivity is measured by lines of code committed per day. There was a day where I actually removed 100 lines of code and rewrote it in 50. The result was a much more efficient algorithm, but according to the metrics used to evaluate performance, I did negetive work. At least I'm only expected to average +12 lines of code committed per day. :-)
"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."
I don't have the perfect solution (yet) but there is a definite difference, a sort of "feeling of entitlement" present in many coders who came along after the microcomputer wars of the 1980's.
They expect things to "work as advertised"...and a heartbroken when their project ships late due to unexpected difficulties with the environment/ide/framework/etc.
"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..."
Me too. But for another reason...
I almost never get real specs. But once a user sees a prototype, they are suddenly no longer bashful. They'll tell you how it really should be.
Someone on Slashdot commented and said that they're company has 2 phases for developing software. The initial prototype phase where the hackers get to use whatever tools they need to write the software, just to get something out there. The point is to figure out the specs based on that and then once they do that, once they have the scope of the software determined, then they can just write a spec and feature list out and hand it over to the engineers who turn the prototype into an actual product (with documentation, full-scale test suites, etc.)
Absolutely, and I don't think this is bad, just a frame of mind.
Let's face it, it's just easier to know what you want once you have something in your hands to play with. I think instead of resisting this we should adopt tools and processes which make it easier. When I've had the ability to facilitate a project in this way, the result has always been of superior Quality compared to other methods.
Nayar is actually right, in a way. Hackers should be considered unemployable by companies like HCL. From what I know of shops like that -- and I've interacted with various over the years -- a hacker would be profoundly unhappy working there.
No no no, just remember where to look. HN's ideas of business processes and best practices are quite different from what you see in body shops like that.
Software developers are sometimes called upon to program, sometimes hack. A lot of what a software developer spends time doing is neither, working closely with all the other roles in a development shop to deliver software. Working with business owners, architects, junior devs, documentation, QA, operations, support, and the users requires a lot of time spent not programming and not hacking.
But remember not to fall into the trap of thinking of yourself as an engineer. Two different fields entirely and what may work in one field, may not work in the other field.
Engineers deal with physical products and fully-specified tech specs and all sorts of extra business stuff that is just a hindrance to a software developer (or are impossible to implement, like a full tech spec, all software has a creative component that's hard to control).
Let's tell it like it really is...
The India shops (and many U.S. shops, too) love methodologies like UML because they make someone who does not know what he is doing appear as if he did.
This is especially important for maintaining margins above 50%.