Saturday, June 28, 2008

Dynamic Languages

This is a bit old, but Steve Yegge has an interesting talk about dynamic languages that essentially boils down to this:  the problems inherent in dynamic languages are often not significant to your development - they aren't too slow for what you want to do, and the speed of development may outweigh the rest of the problems - if you can get a slightly too slow good version out months earlier, and seize the market, your team can optimize the next version in the spots that are too slow, and you can save time by optimizing the ones your customers really need to be fast.


One bit made me laugh, mainly because I had a similar thing happen to me just last year - "And [my intern] is, like, "well I understand the argument" and I'm like "No, no, no! You've never been in a company where there's an engineer with a Computer Science degree and ten years of experience, an architect, who's in your face screaming at you, with spittle flying on you, because you suggested using, you know... D. Or Haskell. Or Lisp, or Erlang, or take your pick."




Technorati Tags --
, , ,
HTTP

Friday, June 27, 2008

Yet Another VC Who Devalues Programmers

I guess the exchange rate of the rupee to the dollar has gotten all the VCs thinking that because Indian programmers are cheap, everyone else should be cheap. Never mind the relative costs of living.


Tell you what, Mr. Hoffman, how about you take a 20% cut now, just to see if you really want to keep working at your current job. If you're really good, you'll get a raise eventually that will put you above the market average.

What do we have to do to get people to realize that programming is as much work as selling, more being a CEO?



Technorati Tags --
, , ,
HTTP

Wednesday, June 25, 2008

When You Can Snatch The Hashtable from My Hand....

Having been out of the academic world for decades now, I'm not up to speed on the teaching in CS/Programming curriculum these days, but various laments from people hiring lead me to believe that many CS grads are being taught to the industry popular things - Java, Microsoft Visual Studio, etc. - and given at most a cursory glance at CS theory. My own coursework was luckily free of commercial value - I was taught in Pascal.

But this post rang true - students are rarely given much chance to develop data structures, or to see why certain structures are better than others. The closest example I ca recall from my classes was an AI course where we were implementing a game-playing program in Lisp, and the alpha-beta tree I was using to find good moves could make about 3 moves before I ran out of time on the machine. I don't know if any of the colleges these days even have limited time on computers any more - other than the sheer clock time limit between the assignment and the deadline.

Given the large number of specialized data structures that exist, it would be hard to do them all justice, but a course that forced the processing of really big data sets would help - driving home the differences between O(n) and O(log n), for example.

Perhaps the availability of truly large data sets - SETI@home, the Folding project, and others, CS can get more meaningful exercises to show the students the real impacts of careless choices.




Technorati Tags --
, , ,
HTTP

Tuesday, June 24, 2008

Another One Who Hates Programmers

With all the startup buzz going around (Y Combinator, Startup School., etc), there's a lot of people giving advice on how to "do" startups. Now, I have little to no experience with startups, so I can't comment on that advice, but another thread that keeps coming up is the business types denigrating programmers. There are numerous requests by business types the "just need a hacker" to turn their brilliant idea into code, and they'll make millions - and the hacker will make a year or two's salary, because s/he "just coded" the brilliant idea.

And then I read this, by a venture capitalist, and I see it in spades - a wholesale dismissal of programmers as slow and behind the times. It's the same attitude I saw in the 90's, when managers expected the Excel macros the receptionist had written for a company directory was deemed "almost done" and the programmer was expected to turn that into robust multi-user distributed application in 1 week, because the "hard part" was done, all that was needed was a little work.

It's really easy to throw together an application with no requirements but your initial ones, without customer UI expectations, training, testing, scalability (and no, it's not just having cloud processing and hosting - you've got to make sure that it does indeed happen when you need it), and documentation. It's even more fun when you can show up a professional with many other responsibilities.

Nice try. Now support the app.




Technorati Tags --
, , ,
HTTP

Monday, June 23, 2008

Sleeping With The Fishes

Sometimes someone writes something that just sings to you.

I've seen this so many times in my career, even at small companies, that I feel like one of those
little fish that swim in the dark abyss, sometimes drawn towards the dim light that turns out to be the lure of a horror with big teeth.

How to cope? Emphasize the problems, especially in hallway conversations near the offices of management above your direct manager. Point out your original, longer estimates at every milestone discussion.


Technorati Tags --
, , ,
HTTP

Sunday, June 22, 2008

Insecurity, or self-protection?

I'm as guilty of programming faults as anyone, but there's a vein of blame-the-programmers running through the blogosphere. Here's one example, discussing the tendency for programmers to develop in isolation and drop a finished product into the code line, where it's difficult for colleagues to analyze and understand for review.

What is not discussed is the environment that supports this. In many shops, the number of projects exceeds the number of developers, so everyone is always in the middle of multiple features, and the management rarely considers code reviews a worthwhile expenditure of time. It is hard to get the time for a final review, much less getting time from the 2-5 developers to review code in progress multiple times. The XP practice of Pair-Programming is one way to get at least one pair of eyes on code at all stages is also a hard sell to management - they see it as cutting their staff in half, and they already have too much to do!

Another issue is the type of criticism that we tend to get. Many of us are not well-suited to give constructive ciritcism. A cow-orker of mine is prone to call code not meeting her peculiar standards "bullshit" or "stupid", even if it meets the requirements provided the developer. I'm not partial to having such words applied to my efforts, especially if it's early in the development when my ideas are not fully formed.

But even if the programmers are less harsh, the fact remains that managers do not see reviews as progress, and it's rare to get the time to do them.



Technorati Tags --
, , ,
HTTP

The Limits of Self-Organization

I ran across this about a month ago, and it struck a nerve.

Now, as my previous entries will show, I'm not a big fan of typical corporate management, with the political games, favoritism, bad decision-making, etc. But I will step up to defend management in a corporation as being the only ones capable of doing a necessary job - keeping focus on the corporate target.

The post I read laments that at a conference, self-organization was a virtue, while it seems lacking in the company he works at. But there is a key difference - the corporation has a goal that is not defined by the participants, and management is the one group that can keep development from mistaking the intent of that goal.

Sometimes the corporate goal is just plain boring - and the developers, as we are wont to do, will want to add something to make things interesting, which will introduce risk.

Now, the Extreme Programming mavens will leap to claim that the developers will not add features that are not covered by a user story. True enough, but a department that is using XP will also have better communications - not a typical corporation.

So it seems a little odd to blame the developers for lacking initiative without blaming the corporate management for making them need more info.



Technorati Tags --
, , ,
HTTP