Not that I need much.....
It was written for "artistic" types, but applies to software types
Points 3,4,9 and 10 resonate most, pity too many developers feel differently about OOP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, March 23, 2007
Wednesday, March 21, 2007
Like I said......
Someone else has seen the "Back where I used to work, we did things different" syndrome
Clinton Forbes
So remember folks, don't treat your new cow orkers like idiots, or they will hate you for it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Clinton Forbes
So remember folks, don't treat your new cow orkers like idiots, or they will hate you for it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, March 02, 2007
Turnabout's Fair Play
Today, driving home, I had a mild epiphany.
You have no doubt heard the manager-speak where they call a problem "an opportunity", one of the more hated turns of phrase I know of.
Well, I just thought that what's sauce for the goose is sauce for the gander...
When managers discuss bugs, refer to them opportunities. You know, a chance to improve the codebase.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
You have no doubt heard the manager-speak where they call a problem "an opportunity", one of the more hated turns of phrase I know of.
Well, I just thought that what's sauce for the goose is sauce for the gander...
When managers discuss bugs, refer to them opportunities. You know, a chance to improve the codebase.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, February 17, 2007
Another Stupid Cliche - The Ninja Rants Again
It always happens, in every job. Some well-meaning managerial type has a chat with you about dealing with external issues, and that phrase comes up:
"You have to own the problem."
This always happens when the discussion is about someone outside your area has a problem and they want your help. They can't be bothered to provide all the necessary info, even if they are well-aware of what is needed, and they can't be bothered to follow-up on the issue, so you have to "own the problem" and spoon-feed them the answers, and god help you if you don't.
I always wonder why I am the one who has to "own the problem", and not the person who brings the problem to me? And why I am expected to be able to solve the problem against all odds without any increase in my authority, budget, or rank? It's particularly galling when you discover that the problem does not lie in your area of expertise, but are expected to pursue the problem to the next expert, instead of informing the one who came ot you, and letting them carry it to the next expert. Why aren't they "owning the problem"?
One of my theories about this is that managers don't want to appear as if their staff cannot solve problems, so they expect their staff to be the ones to "solve" the problem by carrying it to the end. It garners much praise from the upper managers, because they don't have to actually manage the problem. It might be an effect of continual delegation - the upper managers might rightly delegate a problem to an underling, but that underling still has enough authority to encompass the entire solution. This rule falls apart when you reach the lower levels of management, because the solution may not fall under the authority of that delegate, and that causes difficulties - the delegate now cannot command obedience to get the answer. And so the lowest level of management follows the trend, and expects the contributor level to magically influence others at their own or higher levels to help solve a problem that they have less then immediate data about.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
"You have to own the problem."
This always happens when the discussion is about someone outside your area has a problem and they want your help. They can't be bothered to provide all the necessary info, even if they are well-aware of what is needed, and they can't be bothered to follow-up on the issue, so you have to "own the problem" and spoon-feed them the answers, and god help you if you don't.
I always wonder why I am the one who has to "own the problem", and not the person who brings the problem to me? And why I am expected to be able to solve the problem against all odds without any increase in my authority, budget, or rank? It's particularly galling when you discover that the problem does not lie in your area of expertise, but are expected to pursue the problem to the next expert, instead of informing the one who came ot you, and letting them carry it to the next expert. Why aren't they "owning the problem"?
One of my theories about this is that managers don't want to appear as if their staff cannot solve problems, so they expect their staff to be the ones to "solve" the problem by carrying it to the end. It garners much praise from the upper managers, because they don't have to actually manage the problem. It might be an effect of continual delegation - the upper managers might rightly delegate a problem to an underling, but that underling still has enough authority to encompass the entire solution. This rule falls apart when you reach the lower levels of management, because the solution may not fall under the authority of that delegate, and that causes difficulties - the delegate now cannot command obedience to get the answer. And so the lowest level of management follows the trend, and expects the contributor level to magically influence others at their own or higher levels to help solve a problem that they have less then immediate data about.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, January 21, 2007
Software is like an ogre....
...it has layers
(sorry for the Shrek reference....)
Most developers are at least somewhat aware of this, since we all see the usual network protocol stack diagrams with 3-7 layers, and the MVC design pattern/paradigm, and so on.
What I am starting to think is that this pattern is not being used enough. We have our GUI layers, our database layers, and our business logic layers, but we tend to have a single program running as the layer.
After a recent push with work to have a VP's pet project done, I had the chance to build a "server" that was calling several standalone executables to perform specific tasks. What I got from this was that it followed the UNIX way better - I had smaller, easier-to-debug pieces that could be re-used on other projects without having to alter basic code. The big use would be for test harnesses - by having standalone executables, the test crew can write shell scripts to drive their tests, which relieves the development team from having to provide all the integration test code.
Now, this does not work in places where serious speed or efficiency is needed. But many programs are driven by user input, or easily-paced timers, and the benefit of the encapsulation can pay off later.
Also, many developers will point out that libraries can perform similar functions. They can, but alternate use requires they be linked in to the calling program, which can be problematic for testers, who typically have a) less software writing experience, and b) less support structure to write code in.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
(sorry for the Shrek reference....)
Most developers are at least somewhat aware of this, since we all see the usual network protocol stack diagrams with 3-7 layers, and the MVC design pattern/paradigm, and so on.
What I am starting to think is that this pattern is not being used enough. We have our GUI layers, our database layers, and our business logic layers, but we tend to have a single program running as the layer.
After a recent push with work to have a VP's pet project done, I had the chance to build a "server" that was calling several standalone executables to perform specific tasks. What I got from this was that it followed the UNIX way better - I had smaller, easier-to-debug pieces that could be re-used on other projects without having to alter basic code. The big use would be for test harnesses - by having standalone executables, the test crew can write shell scripts to drive their tests, which relieves the development team from having to provide all the integration test code.
Now, this does not work in places where serious speed or efficiency is needed. But many programs are driven by user input, or easily-paced timers, and the benefit of the encapsulation can pay off later.
Also, many developers will point out that libraries can perform similar functions. They can, but alternate use requires they be linked in to the calling program, which can be problematic for testers, who typically have a) less software writing experience, and b) less support structure to write code in.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, January 06, 2007
Being TOO Careful
A program at work gave me a bit of trouble these past two work weeks (the holiday break interrupted the debugging).
It's a process manager for the product, allowing the user to start and stop the various parts of the system, and it also monitors the processes to restart them if they fail. Basically, all the same stuff initd does under Unix, but for the specific system applications.
Now, for some reason, it does not keep its list of child processes in memory, but uses the 'ps' function to get them, filtering the output to eliminate things using the executable name in other ways. However, it expects the executable to be the first thin in the command line section of the output.
That's it - no provision for an interpreted script at all. And my most recent work is a rapid-prototype server in Python. So it can't be controlled from the manager. And it's buried in old, barely managed code, so I'm reluctant to dive into that swamp without managerial mandate.
(To be fair, this is one of the oldest parts of the system, written over a decade ago, so it was probably not a high probability that interpreted languages would be used in the system at that time. But it still was a real pain to have this float out of the miasma of reported bugs coming from the 3 sets of testing staff.)
Fortunately, Python's embedding feature saved me here; I was able to throw together a quick C++ wrapper that would call the Python script, waiting for it to exit. So now I get the monitor to start and stop it cleanly, but keep the useful parts in Python.
There is a plan to move the code more to C++, but the need to do several things that we have no C++ libraries for will keep some Python in the mix.
[Later]
Mea Culpa, Readers! I forgot to relate the moral of this story, in all my bitching and moaning.
The Lesson: When filtering results, the Software Ninja makes sure the filtering code is a) separated into an independent function, and b) make the filtering criteria very clear, so that the next developer to work on the code can change the filtering if necessary, and will understand what is being filtered out.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It's a process manager for the product, allowing the user to start and stop the various parts of the system, and it also monitors the processes to restart them if they fail. Basically, all the same stuff initd does under Unix, but for the specific system applications.
Now, for some reason, it does not keep its list of child processes in memory, but uses the 'ps' function to get them, filtering the output to eliminate things using the executable name in other ways. However, it expects the executable to be the first thin in the command line section of the output.
That's it - no provision for an interpreted script at all. And my most recent work is a rapid-prototype server in Python. So it can't be controlled from the manager. And it's buried in old, barely managed code, so I'm reluctant to dive into that swamp without managerial mandate.
(To be fair, this is one of the oldest parts of the system, written over a decade ago, so it was probably not a high probability that interpreted languages would be used in the system at that time. But it still was a real pain to have this float out of the miasma of reported bugs coming from the 3 sets of testing staff.)
Fortunately, Python's embedding feature saved me here; I was able to throw together a quick C++ wrapper that would call the Python script, waiting for it to exit. So now I get the monitor to start and stop it cleanly, but keep the useful parts in Python.
There is a plan to move the code more to C++, but the need to do several things that we have no C++ libraries for will keep some Python in the mix.
[Later]
Mea Culpa, Readers! I forgot to relate the moral of this story, in all my bitching and moaning.
The Lesson: When filtering results, the Software Ninja makes sure the filtering code is a) separated into an independent function, and b) make the filtering criteria very clear, so that the next developer to work on the code can change the filtering if necessary, and will understand what is being filtered out.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, December 19, 2006
Soft Issues
Last week I was forcibly reminded that people issues are sometimes more important that technical ones.
A Cow-orker dressed me down for an alleged shortcoming in my code - a naming issue in an interface.
To be fair, I had not commented the suspect code to note it was re-using an existing call, with different meaning for the parameter, and I had left some unused code in the file. However, the big issue is that I was accused of not just bad coding, but of something akin to thoughtcrime - I was willing to leave API code unchanged (to help the external developers) rather than change it (to help internal developers). The kicker was that the code under consideration was actually correct for the one use - I had re-purposed that call for an internal issue, making things much better for the end user, at the cost of two differing uses for a parameter in the call.
Frankly, the incident pissed me off for almost the whole week, and more so because it was totally due to the abrasive manner of this cow-orker. If I had been approached with a simple questioning attitude, the issue would have been explored and settled with no rancor. But because my technical skills were called into question, I took (understanable) offense, and the incident escalated.
The moral of the story is - never assume that you have the whole story for something in a system when that story involves something you consider stupid and a developer that has significant real experience. Always tread with caution, and a humble attitude will get you farther than arrogance, and will save you from eating crow.
I am interested in seeing if I get an apology.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
A Cow-orker dressed me down for an alleged shortcoming in my code - a naming issue in an interface.
To be fair, I had not commented the suspect code to note it was re-using an existing call, with different meaning for the parameter, and I had left some unused code in the file. However, the big issue is that I was accused of not just bad coding, but of something akin to thoughtcrime - I was willing to leave API code unchanged (to help the external developers) rather than change it (to help internal developers). The kicker was that the code under consideration was actually correct for the one use - I had re-purposed that call for an internal issue, making things much better for the end user, at the cost of two differing uses for a parameter in the call.
Frankly, the incident pissed me off for almost the whole week, and more so because it was totally due to the abrasive manner of this cow-orker. If I had been approached with a simple questioning attitude, the issue would have been explored and settled with no rancor. But because my technical skills were called into question, I took (understanable) offense, and the incident escalated.
The moral of the story is - never assume that you have the whole story for something in a system when that story involves something you consider stupid and a developer that has significant real experience. Always tread with caution, and a humble attitude will get you farther than arrogance, and will save you from eating crow.
I am interested in seeing if I get an apology.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)