I had a really devious thought the other night. It's totally hypothetical, but it fits so well into the conspiracy theory mindset that I had to put it out for kicks.
The rise of outsourcing/offshoring in IT around 2000 caused great concern in the developer population, because we saw our livelihood disappearing. About 2004, a number of reports surfaced that claimed that IT/Software jobs would return, due to 2 things - the rise of the local job demand in the offshoring nations, and the retirement en masse of the large number of Baby Boomer developers, enjoying their retirement money, bouyed by the growing housing market. This would drastically cut the number of working developers, forcing the companies that employ them to raise salaries again, like in the dot-com boom.
This year, the housing market collapsed, taking out a large segment of the stock value. This destroyed the value of a majority of the retirement accounts of all these soon-to-retire developers, making them more likely to stay in the workforce, keeping the numbers high, and salaries low.
The greatly wealthy were not hard hit by this collapse; after all, losing 75% of 4 billion (the amount George Lucas was worth) still leaves you with 1 billion. [Note - I don't think George was in on it, he's just a well-known individual]
But having your 401k drop from $1M to $250K means you will probably have to keep working, and your best work is that which you've been doing for the past 30 years.
It will be interesting to see how this plays out.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, December 29, 2008
Friday, December 19, 2008
Letting Your Developers Excel
As every developer knows, it's hard to soar with the eagles when you're surrounded by turkeys. And by turkeys I don't mean your cow-orkers, but your environment.
As 37signals, and Jeff Atwood describe, a workplace that doesn't trust you, or won't provide necessary equipment won't let you achieve your best.
Now, it's hard to make your bosses extend more trust to you, but you can gain some of the same effects by skunkworking your situation - firewall your development environment from management; extend your estimates a little; frame the dialog with management in your terms - ask what they want as the end result, not how they want it done.
Budgets make technology stuff harder, but use Jeff's numbers to show how quickly your purchases will pay for themselves - show your compile times, the time spent switching workspaces instead of having 2 monitors, and show how the better equipment will help them.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
As 37signals, and Jeff Atwood describe, a workplace that doesn't trust you, or won't provide necessary equipment won't let you achieve your best.
Now, it's hard to make your bosses extend more trust to you, but you can gain some of the same effects by skunkworking your situation - firewall your development environment from management; extend your estimates a little; frame the dialog with management in your terms - ask what they want as the end result, not how they want it done.
Budgets make technology stuff harder, but use Jeff's numbers to show how quickly your purchases will pay for themselves - show your compile times, the time spent switching workspaces instead of having 2 monitors, and show how the better equipment will help them.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, December 17, 2008
Burnout
I'm suffering a bad case of burnout. Work has been a lot of conflicting bug fixes, nearly one hundred arbitrary deadlines, every release getting patch branches, and it's gotten me down. The work is too simple and too rushed to be satisfying. The matrix management has all the managers giving me "top priority" tasks, each wanting their own to be really top priority. Other development teams are trying to obsolete portions of our product. Customers are pushing their systems past all reasonable limits because our marketing dept did not push back.
In short, I'm sitting in the middle of a big helping of Life Sucks right now.
My hope is that the holidays will get me some much-needed sleep and downtime, and I will start up out of the pit.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
In short, I'm sitting in the middle of a big helping of Life Sucks right now.
My hope is that the holidays will get me some much-needed sleep and downtime, and I will start up out of the pit.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, December 15, 2008
No Comment!
Comments - a contentious subject
Every developer has horror stories of the monster codebase without comments, or worse yet, the one with misleading comments.
And last July I saw this - Jeff Atwood advocating coding without comments. When I see these sorts of articles, I wonder how many multi-developer. multi-process systems the authors have worked on. While I agree that it's hard to work on code with bad comments, if the code has seen several developers, the comments may be all that exists to explain why things are being done.
Jeff's example is relatively trite - code that implements math functions is almost by definition clear in intent. If you have a function that implements business logic for a niche industry that will not have a clear meaning to a new developer, or a seasoned one that has been away from the code. And that's the reason comments are necessary - no matter how good the other documentation may be, the developers will be in the code first, so that's where you need to have the most info useful to programmers.
So when you are coding, add comments that explain the logic behind the code. Most of it might be doable with correctly-named function names, and variables, but some things are not so easily explained and need a paragraph or two to get that across.
Not this:
a++; // increment a
But this:
a++; // the hardware uses 1-based numbering
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Every developer has horror stories of the monster codebase without comments, or worse yet, the one with misleading comments.
And last July I saw this - Jeff Atwood advocating coding without comments. When I see these sorts of articles, I wonder how many multi-developer. multi-process systems the authors have worked on. While I agree that it's hard to work on code with bad comments, if the code has seen several developers, the comments may be all that exists to explain why things are being done.
Jeff's example is relatively trite - code that implements math functions is almost by definition clear in intent. If you have a function that implements business logic for a niche industry that will not have a clear meaning to a new developer, or a seasoned one that has been away from the code. And that's the reason comments are necessary - no matter how good the other documentation may be, the developers will be in the code first, so that's where you need to have the most info useful to programmers.
So when you are coding, add comments that explain the logic behind the code. Most of it might be doable with correctly-named function names, and variables, but some things are not so easily explained and need a paragraph or two to get that across.
Not this:
a++; // increment a
But this:
a++; // the hardware uses 1-based numbering
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, December 14, 2008
Passion - Do You Have It? And For What?
When you have passion for your work, it hardly seems like work - you want to solve the problems in front of you. You get a kick from constructing the solution in code.
The dark side of passion is that it often get used as a club to convince you to work long hours under bad conditions because doing otherwise is "unprofessional" - if you are professional, you are supposed to love the work.
Bull. You are professional if you hate being made to ship unfinished product just because someone in Sales needed a bigger bonus this quarter, so they pulled in a deadline. You hate working overtime to fix bugs that made it to the field because of those rushed releases.
Over on Creating Passionate Users (apparently defunct) is a post about this topic, and although it is written more for game developers, it rings true. Passion should not be getting you to do things you don't like; it should be getting you to do things you love.
So look around at your job, and see if you can find the passionate developers - and you will find they are not the ones who don't care about working overtime, just to be seen as "team players" - they're the ones who prefer to make their code better so that they rarely need to work overtime.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The dark side of passion is that it often get used as a club to convince you to work long hours under bad conditions because doing otherwise is "unprofessional" - if you are professional, you are supposed to love the work.
Bull. You are professional if you hate being made to ship unfinished product just because someone in Sales needed a bigger bonus this quarter, so they pulled in a deadline. You hate working overtime to fix bugs that made it to the field because of those rushed releases.
Over on Creating Passionate Users (apparently defunct) is a post about this topic, and although it is written more for game developers, it rings true. Passion should not be getting you to do things you don't like; it should be getting you to do things you love.
So look around at your job, and see if you can find the passionate developers - and you will find they are not the ones who don't care about working overtime, just to be seen as "team players" - they're the ones who prefer to make their code better so that they rarely need to work overtime.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, December 13, 2008
A List I Need To Re-read Soon
One of the hazards of developing for a large company is that you tend to fall into a niche, due to the managerial wont for having "Experts" on parts of the system easily identifiable and accessible. So you get more of the work on the parts you know well, because you can solve probelms faster (for field issues) and can plan faster (for new development).
The downside of this is that you can lose sight of how your skill set really maps up to others, because you're working in an area where you are supported by your background knowledge, as opposed to your programming skill.
I'm feeling this lately, since I've been stuck in customer support Hell for a while. So when I consulted with a cow-orker about an issue, and determined that code I was working on was exhibiting signs of voodoo programming (No chickens were harmed in the production of this code), I was reminded of this list. It's a little tongue-in-cheek, but it has points to ponder.
Too often we forget to revisit the basics of the craft - or time pressures make us fall back to old code practices that are not so good anymore. So take some time this holiday season to look at your skill set and see if you could use some polish in the basics.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The downside of this is that you can lose sight of how your skill set really maps up to others, because you're working in an area where you are supported by your background knowledge, as opposed to your programming skill.
I'm feeling this lately, since I've been stuck in customer support Hell for a while. So when I consulted with a cow-orker about an issue, and determined that code I was working on was exhibiting signs of voodoo programming (No chickens were harmed in the production of this code), I was reminded of this list. It's a little tongue-in-cheek, but it has points to ponder.
Too often we forget to revisit the basics of the craft - or time pressures make us fall back to old code practices that are not so good anymore. So take some time this holiday season to look at your skill set and see if you could use some polish in the basics.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, August 02, 2008
Who are you likely to be working with?
Last Wednesday, after looking at a process module written by a cow-orker that was totally alien to any of the codebase we have, I was reminded of the words of a former boss - "Don't be clever". His point was that if you are being clever, you are making things hard to understand, and that makes the code harder to work with. This post makes the same point, near the end, when discussing exceptions and execution flow. The odds are great that your fellow programmers are NOT the geniuses being hired by Google, or running a startup funded by Y-Combinator, so you need to write your code so that it is easy to understand and debug.
You also need to write programmer documentation in the CVS system, so that the next developer does not have to hunt it down in whatever document storage system you use - it needs to be write next to the code, and it needs to be clear.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
You also need to write programmer documentation in the CVS system, so that the next developer does not have to hunt it down in whatever document storage system you use - it needs to be write next to the code, and it needs to be clear.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, July 23, 2008
Stretching My Brain, Lisp Edition
So as I bounce around the Web, I'm seeing a lot of chatter about Lisp. I had learned Lisp long ago, for an AI course, but I haven't used it since. But the wave of new interest has caught me, and so I searched for some tutorials and the like.
The most interesting one is a list of 99 problems, with some solutions. I've gotten to #16, with #9 making me cheat. It's been interesting trying to get into the Lisp mindset, which is very different from the procedural and OO views of the world.
It's a fun challenge, and I'll post an update as I go along.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The most interesting one is a list of 99 problems, with some solutions. I've gotten to #16, with #9 making me cheat. It's been interesting trying to get into the Lisp mindset, which is very different from the procedural and OO views of the world.
It's a fun challenge, and I'll post an update as I go along.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, July 19, 2008
This Is Madness!
Jeff Atwood's Coding Horror had this little tidbit about a week ago. I was intrigued, and went to the wiki for Spartan Programming and read up a bit. Jeff comes out as more positive towards Spartan Programming than not.
It starts out well - the goal is to eliminate complexity, making the code as simple as possible. They also seem to have an admirable aim to make sure that things are spelled correctly in code and comments - I can't recall how many times I've cringed because the previous programmer misspelled a word used as a variable all throughout a program.
They prefer the K&R coding style for its vertical compactness, which I disagree with, but that's a Holy War for another time.
They advocate pushing variables as far down in scope as possible, and eliminate the use of placeholder variables as much as possible. Loops with foreach are preferred to for(;;) loops, etc.
And then they get flaky. They contend that mere number of characters on a line increase complexity, and so they advocate using very short, even one character names for local variables, and parameters into functions. This is counter to nearly all the information I've read on how people read - the added semantic information of a meaningful variable name makes code easier to understand, not harder. The next programmer will have a better time understanding the code if the interface has enough meaning to make the usage clear. There is a small point of matching the domain usage - if writing a function to extract roots of quadratic equations, it's ok to use the common math terms, but I find it almost unbelievable that copy(char *s, char *d, int l) is considered significantly better than copy (char *source, char * dest, int length).
The wiki states that the term "Spartan Programming" was coined in 1996, which makes some sense to me - the author(s) had to have learned programming after the common C/C++ compilers had gained the longer identifiers. I learned in the era when you had maybe 8 unique characters in an identifier, and I learned that having longer names was a blessing.
La plus la change, la plus la meme chose. I expect to see someone soon campaigning for assembly as the best way to handle the excessive complexity of C. With only 3 tokens per line, it is hard to beat!
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It starts out well - the goal is to eliminate complexity, making the code as simple as possible. They also seem to have an admirable aim to make sure that things are spelled correctly in code and comments - I can't recall how many times I've cringed because the previous programmer misspelled a word used as a variable all throughout a program.
They prefer the K&R coding style for its vertical compactness, which I disagree with, but that's a Holy War for another time.
They advocate pushing variables as far down in scope as possible, and eliminate the use of placeholder variables as much as possible. Loops with foreach are preferred to for(;;) loops, etc.
And then they get flaky. They contend that mere number of characters on a line increase complexity, and so they advocate using very short, even one character names for local variables, and parameters into functions. This is counter to nearly all the information I've read on how people read - the added semantic information of a meaningful variable name makes code easier to understand, not harder. The next programmer will have a better time understanding the code if the interface has enough meaning to make the usage clear. There is a small point of matching the domain usage - if writing a function to extract roots of quadratic equations, it's ok to use the common math terms, but I find it almost unbelievable that copy(char *s, char *d, int l) is considered significantly better than copy (char *source, char * dest, int length).
The wiki states that the term "Spartan Programming" was coined in 1996, which makes some sense to me - the author(s) had to have learned programming after the common C/C++ compilers had gained the longer identifiers. I learned in the era when you had maybe 8 unique characters in an identifier, and I learned that having longer names was a blessing.
La plus la change, la plus la meme chose. I expect to see someone soon campaigning for assembly as the best way to handle the excessive complexity of C. With only 3 tokens per line, it is hard to beat!
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, July 16, 2008
Ninja, Heal Thyself!
Ok, so sometimes you realize that you are not doing everything you need to do. Today I got a good helping of crow when a new developer was unable to smoke-test a modified API because I did not have a ready-made emulator for the other side of the interface. I also totally missed a feature of another API, even when I was looking at it (D'oh!) - which led to a day's worth of lost time due to the ensuing concern over the thought-absent feature.
So tomorrow I get to go into That Place and hand out a few dozen mea culpas, and get cracking on fixing those two issues. I'll help the new developer expand the emulation code we do have to support at least the sequencing we need for the new API calls, and I will volunteer to assist the coding to use that feature I missed and so delayed the development.
I also need to get off my ass and discover some motivation to finish revising some documentation.
All right, enough whining......
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So tomorrow I get to go into That Place and hand out a few dozen mea culpas, and get cracking on fixing those two issues. I'll help the new developer expand the emulation code we do have to support at least the sequencing we need for the new API calls, and I will volunteer to assist the coding to use that feature I missed and so delayed the development.
I also need to get off my ass and discover some motivation to finish revising some documentation.
All right, enough whining......
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, July 06, 2008
More Code Kata
More on the benefits of Code Kata
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, July 03, 2008
Cross Purposes (reviews that have no followup)
Sometimes you run across people or departments that have a wholly different understanding of what the job is.
The best thing to do is to do your best to avoid committing to something untenable in the immediate meeting, and then try to get a meeting with the highest-up person in the other group, to make sure they understand that you do not plan on continuing to let them drive this process. Reviews are for determining if there are issues, and correcting them via compromise, and only then signing-off. Any attempt to bulldoze through the correction part will result in even later finishing, due to errors and impossible requirements.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The best thing to do is to do your best to avoid committing to something untenable in the immediate meeting, and then try to get a meeting with the highest-up person in the other group, to make sure they understand that you do not plan on continuing to let them drive this process. Reviews are for determining if there are issues, and correcting them via compromise, and only then signing-off. Any attempt to bulldoze through the correction part will result in even later finishing, due to errors and impossible requirements.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Auren Hoffman seems to think that good programmers should be willing to be undervalued at the hiring, with the unspoken (and therefor unenforceable) promise of getting more than market value in time as raises are doled out. And this is not even the promise of big money euity - it's just salary!
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, June 20, 2008
Speed Coding
One of the more interesting analogies I've seen recently in programming practice is the equating of programming, a mental skill, with a physical skill (karate, painting, etc). This has been expressed as the Code Kata, Code Kumite, and as Software as Performance Art, among other examples.
This idea get the Ninja Seal of Approval(tm). I wish I practiced it more often. Normally, a developer will do this when learning a new language - we take a problem we've done before, and redo it in the new language, honing the program with our experience. We less often work the improvement within a language we already know - improving the performance or the storage, or simplifying it.
For some of us, the projects we are working on have sufficient growth to allow us to improve the speed or memory usage as part of the routine software maintenance. If we don't get this, perhaps we should think about these drills in programming as part of our mental exercises.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
This idea get the Ninja Seal of Approval(tm). I wish I practiced it more often. Normally, a developer will do this when learning a new language - we take a problem we've done before, and redo it in the new language, honing the program with our experience. We less often work the improvement within a language we already know - improving the performance or the storage, or simplifying it.
For some of us, the projects we are working on have sufficient growth to allow us to improve the speed or memory usage as part of the routine software maintenance. If we don't get this, perhaps we should think about these drills in programming as part of our mental exercises.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Programmer Macho
Programmers are as competitive as anyone else, but since much of our work is mental, and therefor difficult to judge at a glance, we look to what we used to build the system as the criterion for success.
Of course, being the fractious sorts that we are, we all are using different yardsticks. Some judge by the age of the language, or the esoteric-ness of the language, or the purity of expression, popularity, or even the proximity to machine code.
We have our art school types, who champion languages that nobody else uses, and drop them when they become "common", and our Utilitarianists - the best language is the one that more people are using.
We often consider the things we know best as the standard, and other opinions be damned.
Some of it is protection of our investment - of time, of effort, of mental space. Some of it is our almost innate urge to put our own 2 cents in, and some may just be truth.
Of course, telling the difference is the trick. Let me know if you have a trick to tell this.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Of course, being the fractious sorts that we are, we all are using different yardsticks. Some judge by the age of the language, or the esoteric-ness of the language, or the purity of expression, popularity, or even the proximity to machine code.
We have our art school types, who champion languages that nobody else uses, and drop them when they become "common", and our Utilitarianists - the best language is the one that more people are using.
We often consider the things we know best as the standard, and other opinions be damned.
Some of it is protection of our investment - of time, of effort, of mental space. Some of it is our almost innate urge to put our own 2 cents in, and some may just be truth.
Of course, telling the difference is the trick. Let me know if you have a trick to tell this.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, June 15, 2008
Killer (Ninja) Instincts
As quite a few people writing about programming have noted, there is a strong vein of creativity in programming. The feeling when that flash hits your brain is one of the coolest things in the world.
I've always said that programming is weaving with logic - building from thought itself. And so when those insights arrive, its unreal.
After a number of years programming, you start to have a sense of "rightness" about the direction your are taking with code, as this blog post notes. Sometimes it's a vague feeling, and sometimes it's a solid idea. If you get one of these feeling, GO WITH IT!
Every time I've failed to listen to this little voice in my head, I've seen the programming so sour. Typically, at the current stage of my career, it's been architectural issues, but they can be at any portion of the development process.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
I've always said that programming is weaving with logic - building from thought itself. And so when those insights arrive, its unreal.
After a number of years programming, you start to have a sense of "rightness" about the direction your are taking with code, as this blog post notes. Sometimes it's a vague feeling, and sometimes it's a solid idea. If you get one of these feeling, GO WITH IT!
Every time I've failed to listen to this little voice in my head, I've seen the programming so sour. Typically, at the current stage of my career, it's been architectural issues, but they can be at any portion of the development process.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, June 13, 2008
Lost in My Own Code
Decades ago, when I was first learning programming, there were only a few interactive terminal systems on campus. You had batch programming with cards, usually. Now, it wasn't like the real old-timers - there were departemental staffers on hand to drop your card deck into the reader right when you showed up, but you often had to wait hours for your job to reach the front of the queue and your output to print. So it was costly to run a program with errors. The result of this was that I would spend a significant amount of time looking over my program for syntax errors, logic errors, etc. I had plenty of time to retype a card, but only so many read, queue, process, print runs I could fit into the day.
These days, its easy to compile and run. Heck, with interpreted languages, you don't even compile. And this seduces me into the problem this post talks about - One More Try. Now, this is different from a debugging session, because it might not be my code, and I might be looking for an issue in a library. But if I am writing new code, and I run it, find it fails, I'm way too easily lured into the rapid tweak/build/run cycle, and that leads to long nights, because I don't stop to see what's really happening. Sometimes I can't see it, but if I stop, look at the code, and decide where things might be going wrong, I can at least put log messages or other debug at the right places.
The Ninja Lesson - seek to understand the essence before you act to change it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
These days, its easy to compile and run. Heck, with interpreted languages, you don't even compile. And this seduces me into the problem this post talks about - One More Try. Now, this is different from a debugging session, because it might not be my code, and I might be looking for an issue in a library. But if I am writing new code, and I run it, find it fails, I'm way too easily lured into the rapid tweak/build/run cycle, and that leads to long nights, because I don't stop to see what's really happening. Sometimes I can't see it, but if I stop, look at the code, and decide where things might be going wrong, I can at least put log messages or other debug at the right places.
The Ninja Lesson - seek to understand the essence before you act to change it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, June 11, 2008
Ninja Secrets of Software Development
I spent a good portion of today writing a filter, to prevent some destinations from being sent certain types of messages. I was essentially making a quick hack to cover for a failure in another group, the developers of the code at the destination that would incorrectly handle the messages. So I was having to write this fairly quickly, and get it into a testbed ASAP, so it could be verified as working, and sufficiently flexible to serve for the (hopefully) short period of time before the destination code is fixed.
The fact that I was having to read from a configuration file for the ID of the destinations to filter made me realize that a Software Ninja should follow the historical example, and have a bag of tricks handy for just such an emergency. When surprised by a pop-up deadline, the Software Ninja can throw caltrops on the trail to slow down pursuit, and escape. In this case, the caltrops would be snippets of pre-packaged code that can be quickly pasted into the project to solve the immediate problem, and later improved or removed as desired.
These snippets are not necessarily code residing in the project itself, but a collection of functions, methods, classes, and whatnot, kept in your private workspace, that you can use to mold changes in the project code when there is no existing code in the project to work with. It should be in whatever languages you develop in, and as you go, glean more from the project. You're looking for common small tasks that span all types of projects.
In my example, I needed to read a text file produced from a database unload, parse it into fields, and save some of the fields for later use, in a collection that resized as needed. It's teh type of routine you find in many projects, so I will add it to my bag of tricks.
And you can generalize them a little. It's quite common for the data source to change as a project evolves. It starts out as a flat file, grows to a CSV file dumped from a spreadsheet, then to a database table. Your snippets can relate to each other - have a flat file reader that can parse fields separated by arbitrary characters (strtok_r is your friend in C++, as split() is in Perl and Python), and a database table reader that pulls fields out of a table, and they feed into a routine that returns a dynamically-sized collection. If you're writing in Java, you may need a routine to read in properties files. For shell scripts,
a whole set of routines for reading from files, accessing databases via SQL, or grabbing a web page with curl may suit your needs.
So keep an eye out for useful snippets, and grab them for your collection. And the next time a manager springs a deadline on you, your Ninja response will throw pepper in their eyes and escape into the shadows.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The fact that I was having to read from a configuration file for the ID of the destinations to filter made me realize that a Software Ninja should follow the historical example, and have a bag of tricks handy for just such an emergency. When surprised by a pop-up deadline, the Software Ninja can throw caltrops on the trail to slow down pursuit, and escape. In this case, the caltrops would be snippets of pre-packaged code that can be quickly pasted into the project to solve the immediate problem, and later improved or removed as desired.
These snippets are not necessarily code residing in the project itself, but a collection of functions, methods, classes, and whatnot, kept in your private workspace, that you can use to mold changes in the project code when there is no existing code in the project to work with. It should be in whatever languages you develop in, and as you go, glean more from the project. You're looking for common small tasks that span all types of projects.
In my example, I needed to read a text file produced from a database unload, parse it into fields, and save some of the fields for later use, in a collection that resized as needed. It's teh type of routine you find in many projects, so I will add it to my bag of tricks.
And you can generalize them a little. It's quite common for the data source to change as a project evolves. It starts out as a flat file, grows to a CSV file dumped from a spreadsheet, then to a database table. Your snippets can relate to each other - have a flat file reader that can parse fields separated by arbitrary characters (strtok_r is your friend in C++, as split() is in Perl and Python), and a database table reader that pulls fields out of a table, and they feed into a routine that returns a dynamically-sized collection. If you're writing in Java, you may need a routine to read in properties files. For shell scripts,
a whole set of routines for reading from files, accessing databases via SQL, or grabbing a web page with curl may suit your needs.
So keep an eye out for useful snippets, and grab them for your collection. And the next time a manager springs a deadline on you, your Ninja response will throw pepper in their eyes and escape into the shadows.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, May 26, 2008
Young Whippersnappers
I ran across this post recently, and I was dumbfounded. That any university-educated programmer would complain about Knuth's relevance. I'll agree that reading Knuth is not a walk in the park, but the foundation he brought to programming cannot be ignored. If the writer of the post were self-educated, I could see this being understandable, but he's not.
I'll admit that formal methods are a pain to do - my brief stint at grad school covered such topics as formal proofs of correctness - which I never fully grasped, and the fast pace of commercial software development rarely allows the time to use the formal ideas, but if you can't at least grasp the utility of them, you really need to consider if you have the proper attitude to develop software as a professional.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
I'll admit that formal methods are a pain to do - my brief stint at grad school covered such topics as formal proofs of correctness - which I never fully grasped, and the fast pace of commercial software development rarely allows the time to use the formal ideas, but if you can't at least grasp the utility of them, you really need to consider if you have the proper attitude to develop software as a professional.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, May 22, 2008
Employee Turnover
This is an interesting take on turnover
The Ninja question is: Where are you on the curve?
Personally, I'm starting to feel way out on the right....
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The Ninja question is: Where are you on the curve?
Personally, I'm starting to feel way out on the right....
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, May 21, 2008
Working Hard, or Hardly Worth It?
Heroics again.
IRL, I'm fighting a bundle of management-set schedules that have no relation to reality. However, I am remaining steadfast in my determination to not work overtime. Since I was not consulted as to effort when these deadlines were set, I hold that I am not responsible for the work.
Now, many will take the stance that I am being unprofessional by not working my best towards this deadline. I point to the studies that show that prolonged excess working hours lead to shoddy work. Anecdotal evidence like this also support the stance.
So when I am dragged into an unrealistic schedule, I hold to regular work hours.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
IRL, I'm fighting a bundle of management-set schedules that have no relation to reality. However, I am remaining steadfast in my determination to not work overtime. Since I was not consulted as to effort when these deadlines were set, I hold that I am not responsible for the work.
Now, many will take the stance that I am being unprofessional by not working my best towards this deadline. I point to the studies that show that prolonged excess working hours lead to shoddy work. Anecdotal evidence like this also support the stance.
So when I am dragged into an unrealistic schedule, I hold to regular work hours.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, May 19, 2008
Workaholics, or Drama Queens?
One job back, I worked for a small company that instituted an "Employee of the Month" award to help boost morale. The only 2-time winner during the existence of this award was a nice guy, and a good programmer, but he won the award for being at the office long hours and fixing problems. But those problems were ones that should have been found before they got that far. This company was rewarding heroics instead of quality. It's a common problem for software companies - the people who get rewarded are those being heroes, while those that do things right the first time get no recognition. And that's just wrong, and this explains, in one of the links.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, May 13, 2008
Software Zealots
I'm setting a record for most posts to this blog in a week.....
One of the biggest team problems you'll run across is the zealotry for the One True Way. Editor wars, code format wars, process wars, ad nauseum.
I read this recently, and it encapsulates the entire view - everyone who holds a strong opinion about software details. But the key takeaway point is that it's almost never a good idea to rewrite something if the only reason is that "I don't like it the way it is"
Case in point, I was given responsibility over a process that needed a significant new feature. By and large, the code was moderately inbred, 10 years of tweaks and fixes. I made two significant refactorings before adding the feature - I changed the polarity of the flag variables - they used 0 to mean set (do X) and 1 to mean unset (don't do X), and changing them to be 1 for set and 0 for unset brought this process in line with the rest of the system; and I replaced 4-5 chunks of repeated code with an extracted method - so that I could clone it for the new feature, which did all the normal stuff, but with additional data to process.
The rest of the code I left alone, not even changing the brace style to suit my common style, because it was safer to not change working code.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
One of the biggest team problems you'll run across is the zealotry for the One True Way. Editor wars, code format wars, process wars, ad nauseum.
I read this recently, and it encapsulates the entire view - everyone who holds a strong opinion about software details. But the key takeaway point is that it's almost never a good idea to rewrite something if the only reason is that "I don't like it the way it is"
Case in point, I was given responsibility over a process that needed a significant new feature. By and large, the code was moderately inbred, 10 years of tweaks and fixes. I made two significant refactorings before adding the feature - I changed the polarity of the flag variables - they used 0 to mean set (do X) and 1 to mean unset (don't do X), and changing them to be 1 for set and 0 for unset brought this process in line with the rest of the system; and I replaced 4-5 chunks of repeated code with an extracted method - so that I could clone it for the new feature, which did all the normal stuff, but with additional data to process.
The rest of the code I left alone, not even changing the brace style to suit my common style, because it was safer to not change working code.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Recognizing Competence
Amazingly, someone is more pessimistic than I am about getting through to management!
It is true that many (most) managers who are not developers have little means to distinguish between good and bad developers. And to make it harder for them, the criteria that some of the responses to the link claim will help managers tell the difference are flawed - it's not always the competent developers who complain about conditions.
From the Ninja Historical Documents, I refer to one of my former colleagues. He was very vocal about all the problems our group had - schedules, technical defects, missing requirements. However, we discovered after he left that he was not nearly as good as he thought he was - a number of key pieces of our libraries that he had coded were not at all functional. So the mere appearance of competence is not enough; the managers will not have the technical chops to tell if any given developer can walk the walk.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It is true that many (most) managers who are not developers have little means to distinguish between good and bad developers. And to make it harder for them, the criteria that some of the responses to the link claim will help managers tell the difference are flawed - it's not always the competent developers who complain about conditions.
From the Ninja Historical Documents, I refer to one of my former colleagues. He was very vocal about all the problems our group had - schedules, technical defects, missing requirements. However, we discovered after he left that he was not nearly as good as he thought he was - a number of key pieces of our libraries that he had coded were not at all functional. So the mere appearance of competence is not enough; the managers will not have the technical chops to tell if any given developer can walk the walk.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Backshoring
So with all the jobs going over to India, what are we to make of this post?
Sounds like programmers are not all interchangeable, and it takes local people who know how the product is to be used, in order to develop good software!
I think that my earlier comments on this subject are valid.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sounds like programmers are not all interchangeable, and it takes local people who know how the product is to be used, in order to develop good software!
I think that my earlier comments on this subject are valid.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, May 09, 2008
Choice of Programming Language
If you frequent any computer-related fora these days (and past days), you'll eventually run across a language war. Nowadays this will probably be Python vs Perl, or C# vs Java; in years gone by you'd see C++ vs C, Pascal vs C, Cobol vs FORTRAN, LIPS vs anything, etc.
Now, we all know that Turing-complete languages are equivalent, so there is no operational difference between any of the main languages. We also know that the syntactic sugar that a language has makes certain things very easy, and others hard, like doing OOP in C - you can do it, but you need to build a great deal of the scaffolding yourself.
So when I read this article by Philip Guo about the relevance of the language libraries and the environment, I found myself nodding in agreement. The biggest factor in language choice is never the strength of the language - it's the existing environment - which languages are already in use, what skills can be hired, does the language have built-in strong libraries, etc. Those are the deciding factors in almost all cases.
And, I might add, politics. Sometimes you face a political fight to use a particular language - there is someone who either forces or prohibits the use of programming language.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Now, we all know that Turing-complete languages are equivalent, so there is no operational difference between any of the main languages. We also know that the syntactic sugar that a language has makes certain things very easy, and others hard, like doing OOP in C - you can do it, but you need to build a great deal of the scaffolding yourself.
So when I read this article by Philip Guo about the relevance of the language libraries and the environment, I found myself nodding in agreement. The biggest factor in language choice is never the strength of the language - it's the existing environment - which languages are already in use, what skills can be hired, does the language have built-in strong libraries, etc. Those are the deciding factors in almost all cases.
And, I might add, politics. Sometimes you face a political fight to use a particular language - there is someone who either forces or prohibits the use of programming language.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, May 06, 2008
La Plus La Change, La Plus La Meme Chose
(The more things change, the more they stay the same)
The Powers That Be at work just dropped me back into the section of the system that I was directed away from (to work the current section), so now I get to work on code that I've been away from for nearly 3 years, and someone else has been stomping around in. Happy, happy, joy, joy. All the code reorganized, functionality that I had no knowledge of when it was added, and I get to add yet another warty version of a protocol that our esteemed colleagues in the other side of the business do not seem willing to consolidate into a sane system.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The Powers That Be at work just dropped me back into the section of the system that I was directed away from (to work the current section), so now I get to work on code that I've been away from for nearly 3 years, and someone else has been stomping around in. Happy, happy, joy, joy. All the code reorganized, functionality that I had no knowledge of when it was added, and I get to add yet another warty version of a protocol that our esteemed colleagues in the other side of the business do not seem willing to consolidate into a sane system.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
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 --
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
Subscribe to:
Posts (Atom)