The Hacker Ethic - Harming Developers?
radar.oreilly.com
radar.oreilly.com
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.
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...
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.
</rant>
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 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.
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.
"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.
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.
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.
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%.
> 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.
Interesting.
I'm not saying there aren't excellent Indian developers. I've also met a few of those. Alas, those are not the majority.
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 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.
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.
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.
If I'm lucky, I will entirely disqualify myself for jobs as a "programmer."
Then there are software developers.
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.
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).
Boo Hoo.