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
Saturday, February 17, 2007
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
Saturday, December 09, 2006
A Digression into AI
I was thinking the other day about the advent to true AI - an artificial mind, and that fraternal twin of a concept, uploading a human mind into a digital device.
When we have these, what are the criteria that determine if one copy of a digital mind is an individual? Making a new flesh person is a long process, and once made, their mind is their own thing. But a digital mind can be copied exactly to another unit (physical memory or whatever). Suppose digital minds are granted voting rights - what if they decide to replicate and register to vote? How could flesh minds ever win a democratic vote? Or should identical copies be considered just one mind, and any number of them count as just one "person"? But after a period of time, those copies would have different experiences and be different "people", would they not?
Just something to consider....
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
When we have these, what are the criteria that determine if one copy of a digital mind is an individual? Making a new flesh person is a long process, and once made, their mind is their own thing. But a digital mind can be copied exactly to another unit (physical memory or whatever). Suppose digital minds are granted voting rights - what if they decide to replicate and register to vote? How could flesh minds ever win a democratic vote? Or should identical copies be considered just one mind, and any number of them count as just one "person"? But after a period of time, those copies would have different experiences and be different "people", would they not?
Just something to consider....
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, December 05, 2006
Look at what you have
Today I found myself somewhat nonplussed by the behavior of 2 cow-orkers who are not dumb, but did not appear to see the forest for the trees.
They were working on an attempt to get a 3rd party to provide a data set to us, for internal use, and were writing impassioned emails to said 3rd party to justify our asking for this data. When this was explained in my presence, I suggested that since a 2nd party was providing us with data that might reasonably include that info, we just get said 2nd party to give us the detailed format of their files (which we might already have), and we extract the desired info from those files.
They seemed rather stunned at this suggestion.
So the Ninja Developer learns from this: if you need some data, look at the data you already have, and see if what you want is what you already have.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
They were working on an attempt to get a 3rd party to provide a data set to us, for internal use, and were writing impassioned emails to said 3rd party to justify our asking for this data. When this was explained in my presence, I suggested that since a 2nd party was providing us with data that might reasonably include that info, we just get said 2nd party to give us the detailed format of their files (which we might already have), and we extract the desired info from those files.
They seemed rather stunned at this suggestion.
So the Ninja Developer learns from this: if you need some data, look at the data you already have, and see if what you want is what you already have.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, December 01, 2006
Too Much Reality Lately
Alas, Dear Reader (I suspect that there is indeed only one person ever reading this...), the vicissitudes of wage slavery have kept me from posting...
[perhaps a confessional tone "Forgive me, Blogger, for I have sinned..."]
Nearly 6 months since the last post. I have been busily diving into new sections of the product, ostensibly to "broaden" my experience.
The Ninja aspect of this has been the lack of input from me on the schedules - dates were set by management without my being asked how long it would take to develop the code. Most deadlines were on the 8-week plan, with the notable exception of the first, which was 10 weeks, 6 of which were consumed by the requirements team pissing away on the requirements document, and the most recent, which went 7 weeks late, and one week pulled in by the VP.
So what is a Ninja to do? Major changes to the product and not enough time to develop it properly? I punted - I developed the new server in Python, driven by text configuration files, and wrote 2 small C++ interface utilities to reach into the product where Python could not. I avoided working significant overtime, and came in almost on schedule - and I plead my case there on the many meetings that wasted my time. ["We will hold daily 2-hour meetings to determine why productivity has plummeted. All the VPs will be there to hear explanations"]. And the decision not to work excess hours lent a Zen-like calm that helped. I did not panic over delays or setbacks.
The lesson to be learned here is that you sometimes need to work outside the system - use a different language, ignore the micro-management, and solve the problems without worrying about how to fit them into the existing framework. I got the chance to use Python in a production project, and I didn't kill myself.
As an aside, I really have to compliment the Python developers - the suite of modules available in the standard package is outstanding - FTP library, tools for handling gzipped tarballs, easy access to the command line, all in the "stock" package. Kudos, folks!
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
[perhaps a confessional tone "Forgive me, Blogger, for I have sinned..."]
Nearly 6 months since the last post. I have been busily diving into new sections of the product, ostensibly to "broaden" my experience.
The Ninja aspect of this has been the lack of input from me on the schedules - dates were set by management without my being asked how long it would take to develop the code. Most deadlines were on the 8-week plan, with the notable exception of the first, which was 10 weeks, 6 of which were consumed by the requirements team pissing away on the requirements document, and the most recent, which went 7 weeks late, and one week pulled in by the VP.
So what is a Ninja to do? Major changes to the product and not enough time to develop it properly? I punted - I developed the new server in Python, driven by text configuration files, and wrote 2 small C++ interface utilities to reach into the product where Python could not. I avoided working significant overtime, and came in almost on schedule - and I plead my case there on the many meetings that wasted my time. ["We will hold daily 2-hour meetings to determine why productivity has plummeted. All the VPs will be there to hear explanations"]. And the decision not to work excess hours lent a Zen-like calm that helped. I did not panic over delays or setbacks.
The lesson to be learned here is that you sometimes need to work outside the system - use a different language, ignore the micro-management, and solve the problems without worrying about how to fit them into the existing framework. I got the chance to use Python in a production project, and I didn't kill myself.
As an aside, I really have to compliment the Python developers - the suite of modules available in the standard package is outstanding - FTP library, tools for handling gzipped tarballs, easy access to the command line, all in the "stock" package. Kudos, folks!
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)