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
Subscribe to:
Posts (Atom)