Monday, May 05, 2008

Stovepipe Specialties

3 on a match - a trifecta of Ninja goodness!

Interestingly, I have just read a post that states the writer has never heard another programmer utter a phrase that I know would be well-worn to anyone reading the Pragmatic Programmers first book.

Kenneth Down, in his May 4th post in "The Database Programmer" blog, states that he has never, in 15 years of programming, heard another programmer say anything like the phrase "Minimize code, maximize data". Yet this has been a well-known adage from the aforementioned book, as part of their general manifesto. And their book was published in 1999!

Now, while I have not read Mr. Down's blog long enough to know much about him, the fact that the blog is "The Database Programmer" lends credence to the idea that it's the narrowness of his field that has kept this technique from common use. Database programmers may not be reading the same books as the general programmer population.

If this is the case, we need to break down the stovepipe specialities that are keeping us programmers from using the knowledge our bretheren mine from the field.



Technorati Tags --
, , ,
HTTP

Programming and Creativity

Another post, in one day? Amazing?!

A Mr. Paul Johnson wrote an insightful article about a fundamental difference between people who get programming and those who don't.

His basic point is that those who don't get it tend to think of the core of programming is a well-known process, one that is amenable to simple industrial process improvements. Those of us that get programming understand that the core of programming is locked in our brains - it is the mix of creativity and juggling of dense concepts that is more akin to writing or art than industrial work.

Now, I'm not promoting programming as an artsy process devoid of control and discipline, but more that the core of programming is the insights that recognize the appropriate patterns that apply to the problem at hand,and how to apply them. This insight is akin to the creative spark, and thus is not amenable to schedules or timing.



Technorati Tags --
, , ,
HTTP

Equity Defined, Programmer's Version

I've started following a few programming-related blogs and aggregations lately, and I saw this post about equity that struck a chord. It's written from the viewpoint of a venture capitalist funding person, but the gist of it is sound - if you, the "Idea Guy" are trying to dole out as little equity in your new company as possible to the guys making the product, you're going to make someone very angry in the future. These days, you cannot afford that - your ex-developers can repeat the process at one of your competitors, leapfrogging your mistakes (the first one out the gate always makes some mistakes), and stealing your market.


Technorati Tags --
, , ,
HTTP

Saturday, April 19, 2008

More on the devaluing....

My job just gigged me this way last week.

I was sent a high-level design document and asked for an effort estimate to implement it. The problem? I had no idea what the feature was, since the design doc had been written almost a year ago, and no developers were in the document review. So I have no idea what this feature is, ho it differs from the current system, and what parts are affected by the changes, except what I read from the design document, and that's very light, having been written by a "software architect" who favors handwaving verbiage (is that a mixed metaphor?) instead of clear requirements.

So I told the manager that I needed to re-review the design doc with the architect, and scheduled a meeting. And until I am satisfied that all the design issues have been thought out and nailed down, I will not be giving an effort estimate - I was burned last year by a design document that left out major portions of the feature, and also was supposed to 'just include' another feature entirely.

The Ninja Lesson: do not give answers that you do not know - always wait until you know enough details to make your answer sufficiently safe for you and your team.



Technorati Tags --
, , ,
HTTP

The value of a programmer

I ran across this the other day, and it rang so, so true.

The problem is not so much that a recent business school grad thinks this way, but that this viewpoint that programming is valueless get propagated up the management chain, where it hangs around all the MBAs and salesmen who make up the upper management ranks. If they think it's easy to write any software, they continue to
a) make ridiculous promises, and
b) under-reward the technical staff

Both of these will sour your geeks to the job.



Technorati Tags --
, , ,
HTTP

Monday, February 18, 2008

Programmer Education, part 2

Picking up from the last post, Jeff Atwood at Coding Horror referenced a Joel Spolsky post about the ideal programmer education where Joel was suggesting a Bachelor of Fine Arts in Programming.

I had a WTF moment on that.

He advocates a 1/3 liberal arts, 2/3s software development curriculum. Perhaps it's just my engineering education, but I found that many of the engineering students I learned with were quite well rounded, while the LA students tended to be missing the hard science side of things – so I'd naturally suggest an emphasis on the engineering side would be better, since we engineering geeks often have enough side interests to round us out.

But more to the point, I can't see how anyone in the business can think that programming is a Fine Art. At best it might be a Practical Art – Fine Arts are things like dance, music, painting. A friend of mine is an artist, but since he was planning to work in advertising, his degree was not a Fine Arts degree. And moreso, given the amount of math that we do make use of in CS/programming, I'd submit that it's at least a craft, and closer to a young engineering discipline. It's still young enough that the edges are fuzzy, and we need a good deal of creativity to solve the issues we face.



Technorati Tags --
, , ,
HTTP

Becoming a Programmer, part 1

A few weeks ago, I ran across a post at Coding Horror where Jeff goes into what he thinks is a better way to teach Computer Science to undergrads. He describes how everything should be done according to best practices – all code in source control, everything needs an installer, every program will have bug reports – and the developer has to fix the bugs. He even states that it would be excruciating.

I think that would be like training an airline pilot to fly by making them take the stick of an F-22 in the middle of a dogfight. There is a certain level of proficiency that is needed before you can progress, and if a student hasn't reached this level, all the trial by fire will do is char them. You need to get them to the point where they are not concerned about how to write code before you make them work in the framework that code exists in. A personal anecdote – I had to learn how to develop code in C under UNIX at the start of my first compiler course; but I already knew how to program in other languages, so C was just new syntax, and UNIX was not too much of a hurdle.

Now, once a student has taken a couple of programming courses, a series of courses that do enforce real-world constraints would be very desirable. All courses after the introductory set could require source control, and some could deal with portions of the real-world, like versioning – start with a simple 2-week project, and once that's done, start adding new features, and some back-porting. Another could deal with code repair – everyone gets a copy of a program that has bugs, and they need to fix them.

Another issue I have with Jeff's post is that it assumes all software is PC-based, web-centric, standalone applications. Developers working on a single server in a large application suite that runs under UNIX, for example, might not need to worry about deployment, because that is a solved issue for that system – their new version of the server will be packaged by the existing tools, and the upgrade issues are part of the DBA's work.


So while there is plenty of room for improvement in the education of a software developer, it shouldn't be like dropping someone onto a speeding motorcycle; it should be like learning to ride a bike - you spend some time with training wheels first.


Technorati Tags --
, , ,
HTTP