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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, May 05, 2008
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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.
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, January 09, 2008
How the Sausage Gets Made
I saw one of Jeff Atwood's Coding Horror posts where he states that nobody cares if the code you write is ugly code or not, as long as it works. While I have some basic agreement, I have a big qualifier - if they are a customer and do not expect to get bug fixes from you, they don't care.
However, if they expect you to fix the bugs they find, or are your manager, they do, or at least should care. Ugly code is harder to maintain, harder to improve, and sometimes harder to find developers to work on.
Jeff has a point, that trying to make code pretty without a business purpose is programmer vanity, but there is a cost to using working, but bad code. This article about technical debt is a good discussion of the tradeoffs.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
However, if they expect you to fix the bugs they find, or are your manager, they do, or at least should care. Ugly code is harder to maintain, harder to improve, and sometimes harder to find developers to work on.
Jeff has a point, that trying to make code pretty without a business purpose is programmer vanity, but there is a cost to using working, but bad code. This article about technical debt is a good discussion of the tradeoffs.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, December 06, 2007
Pilot Error
aThe Job had an interesting filed issue, one where a running process had its RPC binding hijacked by a manual invocation of the same program. This had the puzzling effect of blocking new connections, while leaving existing connections intact.
So the Ninja Lesson from that is twofold:
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So the Ninja Lesson from that is twofold:
- servers must be controlled so that an accidental start will not clobber an already running process
- this means making all your '1-of' initializations must be explicit, and after the check for an already running copy
- you need a check for already running copy
- you need to make it difficult for your servers to be accidentally invoked
- make a user for general observation/maintenance not have execute permission for your servers
- remove the server directory from the path
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)