Yesterday I was reminded of this post. Some people do not understand how things work. Even my upper management.
They want a change of the program's behavior, but they don't want the cost of that change - they don't want to run their tests, or restart their timetables. They want you to somehow make the error go away without making them do anything different, and when you tell them that it's impossible, somehow you are evil from not trying.
If you face this often, you'll need to start programming defensively - making your programs as data-driven as possible, so that you can change behavior without changing code. Now, this obviously fails to help when the problems are code issues (threading, loop limits, etc) - so you'll still need to be ready to deal with the nonsense.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, January 08, 2009
Monday, January 05, 2009
No More Brook's Law?
Every programmer worth his/her salt knows of Brook's Law, from his book The Mythical Man-Month,
and by and large, we tend to agree with it. But this post points out that there may be new tools and methods in software development that may show a way past Brook's Law.
The main factors in this are the open source movement, the leverage of the better languages, and the better understanding of the effects of software interactions.
Open source allows developers to know more about the code by examination than was previously typical. Even in the proprietary world, internal developers expect access to the code they work with.
Better languages are simply an order of magnitude (or more) better than the older languages - we can know access a web page in a single line of code; we have built-in data structures that we can use without having to build linked lists, hash tables, etc. We are able to encapsulate more behavior in less code.
The better understanding of software interactions has allowed us to make better software - we know to separate concerns; we know to build software in layers; we know to make data-driven modules that can handle generic cases or special cases with impunity.
That said, we haven't eliminated the problem, we've just made it small enough to be lost in the noise given the complexity of software we currently develop.
And not all of us work in places and on systems where we get to take advantage of all these new toys. Many of us are still working with lower-level languages, on systems that are too big to get the comprehension of, with unreasonable deadlines.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
and by and large, we tend to agree with it. But this post points out that there may be new tools and methods in software development that may show a way past Brook's Law.
The main factors in this are the open source movement, the leverage of the better languages, and the better understanding of the effects of software interactions.
Open source allows developers to know more about the code by examination than was previously typical. Even in the proprietary world, internal developers expect access to the code they work with.
Better languages are simply an order of magnitude (or more) better than the older languages - we can know access a web page in a single line of code; we have built-in data structures that we can use without having to build linked lists, hash tables, etc. We are able to encapsulate more behavior in less code.
The better understanding of software interactions has allowed us to make better software - we know to separate concerns; we know to build software in layers; we know to make data-driven modules that can handle generic cases or special cases with impunity.
That said, we haven't eliminated the problem, we've just made it small enough to be lost in the noise given the complexity of software we currently develop.
And not all of us work in places and on systems where we get to take advantage of all these new toys. Many of us are still working with lower-level languages, on systems that are too big to get the comprehension of, with unreasonable deadlines.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, January 04, 2009
Good Advice From Google, part 1
I have not had much experience with Test-Driven Development yet, as it's very difficult to insert a methodology from the grassroots, especially one that does not necessarily have the buy-in of all your team, but I like the general tenets of TDD, much like I do those of XP and the more encompassing Agile Development movement.
So here are some tidbits of good advice from Google. I especially like the points about not using "new" except in factory classes, and "ask for, don't look for". I'm less sure about the diss of Singletons - I understand the general point, but can see reasons for them in fact. I'm wondering if this is one of those philosophical points, like Platonic vs Aristotelean views.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So here are some tidbits of good advice from Google. I especially like the points about not using "new" except in factory classes, and "ask for, don't look for". I'm less sure about the diss of Singletons - I understand the general point, but can see reasons for them in fact. I'm wondering if this is one of those philosophical points, like Platonic vs Aristotelean views.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, January 03, 2009
Codebase - Asset or Liability?
We've all had occasion to provide a size of the codebase we're working on for a project, whether for management, or for our own resume, and there is a natural tendency to make the KLOC large - it sounds more impressive to work on or manage a large codebase then a smaller; a project that has lots of code sounds more solid, more reliable.
But there is one school of thought that holds a large codebase as a liability - it is harder to shift it; it has more inertia. And there is some merit to this; a large codebase means that there is greater chance for errors (statistically, at the very least), a greater chance for unwanted coupling, and more places where code has been unwittingly duplicated. So it behooves developers to minimize code, as described here. On the other hand, less code doing the same stuff means you've got denser code, and you are at risk of being clever. Clever code is bad because it obscures its intent, and the next developer to support the code may not be as smart as we are (or like to think we are).
So this means we've got tension between making the code simple, and making it small. The low-hanging fruit of this is reducing redundancy - it's not hard to understand that all I/O is being done through your library functions, for instance. The next best step is to use standard libraries where possible - they have the benefit of being available elsewhere, so your next set of developers are likely to have used them before. A third strategy is good naming - if reading the name does not give you the right idea of what the code does, it will confuse someone later on.
Beyond these steps, you are faced with needing to consider the density of the language you use. The current trends are towards more "advanced" languages like Python and Ruby, which cover much of the ground C/C++ do, but with less cruft, and with nice things like built-in data structures that are easy to use.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
But there is one school of thought that holds a large codebase as a liability - it is harder to shift it; it has more inertia. And there is some merit to this; a large codebase means that there is greater chance for errors (statistically, at the very least), a greater chance for unwanted coupling, and more places where code has been unwittingly duplicated. So it behooves developers to minimize code, as described here. On the other hand, less code doing the same stuff means you've got denser code, and you are at risk of being clever. Clever code is bad because it obscures its intent, and the next developer to support the code may not be as smart as we are (or like to think we are).
So this means we've got tension between making the code simple, and making it small. The low-hanging fruit of this is reducing redundancy - it's not hard to understand that all I/O is being done through your library functions, for instance. The next best step is to use standard libraries where possible - they have the benefit of being available elsewhere, so your next set of developers are likely to have used them before. A third strategy is good naming - if reading the name does not give you the right idea of what the code does, it will confuse someone later on.
Beyond these steps, you are faced with needing to consider the density of the language you use. The current trends are towards more "advanced" languages like Python and Ruby, which cover much of the ground C/C++ do, but with less cruft, and with nice things like built-in data structures that are easy to use.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, December 29, 2008
Conspiracy Theory
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
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
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
Subscribe to:
Posts (Atom)