The blogged wandering of Robert W. Anderson
Last week I got into a morass on some prototyping I’m doing. I had made some changes to several different modules. I ran the standard tests: all good. I decided to run a slightly more obscure test (one that requires special orchestration). Failed. I wasted much time tracking this down. Turns out (of course) that the original code also didn’t work on my machine. Works every where else. In fact, I still don’t know what the problem is, but I’m moving on for now (confident that this problem will resurface somewhere else).
On Friday, my wife and I were talking about the week and I said that it was kind of frustrating. I gave her a little detail on the issue. Her response was:
That seems really common in your job (i.e., frustrating and non-productive time developing software).
That gave me pause. Is this common in my job or common in software development? Is it even common in my job?
Perhaps I have a tendency to talk about the frustrating without talking about the rest (the part that is creative and fulfills a need for artistic expression).
But, it got me thinking. What are the sources of frustration developing software?
Poor Tools / Development tools don’t work
This is generally not a problem; though I have a tendency to use addins from beta or early-access programs. Certainly while tools have been upgraded to work with VS2005, I’ve had a fair amount of uninstall / re-install / disable of addins. I wouldn’t bother, but some addins you just can’t live without (like TestDriven and ReSharper).
Of course the solution is to keep your dev machine fairly clean. Good idea, but hard to do in practice.
Too many manual steps
This is not uncommon when building something for debugging or testing on a remote machine. If between build and debug you have to switch to some other application, manually select files or folders, copy (ftp, . . .) files, restart something, run a test, wait for results, . . . then you have a source of real frustration and, worse, the chance of introducing error.
I try to root out manual processes as soon as possible.
Maintaining someone else’s poorly documented code or code with poor/nonstandard style
Not generally a problem at Digipede, but certainly can be frustrating.
Using poorly documented APIs
This can be frustrating for obvious reasons. One can easily get into a situation of just trying different things until the API works as you expect. Still doesn’t work? Try a different method or change this other argument. Combinitorics quickly can make this a black hole.
As an author of APIs, I know this can be hard to get right. How much documentation is needed? How many user scenarios are enough? How much knowledge should be assumed by the user of the product and other issues (like proper OS configuration, security practices, etc.)?
Other things that are frustrating?
What things am I missing? What frustrates you when developing sofware?
Tags: Programming, software, Software-Development
wrote @ April 26th, 2006 at 12:31 pm
Poorly spec’ed projects and unreasonable delivery dates, which are both a result of engineers not having a say in product planning.
And the good type of frustration that comes from playing with leading edge technologies and systems that don’t have years of sample code, forum posts, or articles behind them.
Expectation management. When working through iterations in an agile environment, the functionality often comes before the presentation. The communication to the client where the “hard part” of coding comes into play is very frustrating.
Integration of poorly documented external systems. Sllightly different that maintaining someone else’s code. We receive external data feeds or mission critical data elements from sources that cannot be replaced and who have no vested interest in making our programming comfortable. However, since their systems “work” the blame tends to fall to our group.
Major players with long release cycles that release unclean code. Microsoft and ESRI are two big ones for us that have repeatedly given us systems that work 90% of the way. Unfortunately, we really needed that 10%. Since we build very unusual applications, we tend to discover more than one new bug , issue or oversight in major tools in every project.
Thanks for the comments:
Kim: Agreed about spec’s, however, my guess is you are talking about big projects with long duration. This is mainly a waterfall problem. In a dynamic environment big projects are poorly spec’d almost by definition.
Good points, Jim. BTW: Expectation management can be a huge frustration both externally and internally.
[...] Last week I posted about some frustrating bug hunting: In fact, I still don’t know what the problem is, but I’m moving on for now (confident that this problem will resurface somewhere else). [...]
Actually bad spec’ing isn’t always a big project problem. When I talk about spec’ing here, it is making sure that features and enhancements are well thought-out and clearly defined. I’ve been assigned requests (not at Digipede) where no one, even the requester, was able to clearly state what they wanted. These requests made it from the product manager, through the development manager, through the lead, to me. That shouldn’t happen. I then would have to go and talk to all the people involved, write up my thoughts, get feedback, meet about the feature, get everyone on the same page, and then finally build it.
I’ve worked in a lot of development environments and not all of them were well run. I guess thinking back on those places I also absolutely hated the political environments. Where decisions were made not because they were the best decisions for the customer, product, or company, but because someone wanted a promotion.
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>