Software Development

Poll: How often do technical frustrations delay your development work?

Justin James feels like for every day he spends writing code that he loses two days to technical frustrations. Is this the case in your development work?

For most of my recent development projects at work, I seem to spend more time being stuck on technical frustrations than on actually developing code. By technical frustrations I am referring to when a minor quirk (or outright bug), deficiency, or other technical problem in a system that you depend upon stops you from writing code.

For example, I recently suffered a multi-day delay on a project because Visual Studio was crashing when I tried to open ASPX files; it took a ticket with Microsoft to find out that the problem turned out to be something that no sane person could have known about or predicted (a unique "quirk" in Visual Studio). Likewise, on another project, I've lost days because the firewall is preventing FTP access from the DMZ to the LAN, which is critical to the project. I feel like for every day I spend writing code, I lose two days to these kinds of problems. What about your work?

J.Ja

About

Justin James is the Lead Architect for Conigent.

29 comments
Osiyo53
Osiyo53

As I often tell my coworkers, if it was as simple as ABC then ANYONE could do it and we'd not get paid nearly as much as we do.

lclaudio.rodrigues
lclaudio.rodrigues

I get frustrated reazonably often by the lack of powerful API's that could release me from having to write almost every piece of boiler plate code that I need. I'd love to concentrate my programming time only on high-level procedures and algorithms that really contains the conceptual body of the work to be done. Maybe I'm dreaming too much about a promising future on programming and maybe after all, this is not really a technical frustration, but a conceptual one.

dkidd23
dkidd23

I run into these type of problems frequently and just switch gears and fix the problem or go in a different direction with my coding, sometimes this is actually a better way to achieve my end goal. In one case about 7 months ago, the work around actually worked better than my real code increasing average search speed from 6.8 sec to less than a second on a moderately large database.

ethanpicklesdad
ethanpicklesdad

I used to work that way until I switched from windows to Mac. I felt like I spent more time fixing things and keeping my system going than actually writing code, developing web sites and getting work done. I almost lost a client because my pc crashed hard and I had nothing to show them for the two weeks worth of work I put into their prospective site. I had to sketch out and story board for them what the site would look and feel like on a dry erase board. If I were them I wouldn't have hired me after that kind of a pitch. Now I don't have to sweat it and I don't waste time always working on my computer to keep it going. I can just focus on getting my work done.

Robert Lerner
Robert Lerner

It's because you're using a bloated IDE. Why not try something designed to be efficient from the get-go, like Notepad++ or similar? Dreamweaver, Eclipse, and most Microsoft IDEs (especially since the 2005 editions came out) have just had aesthetic bloat, instead of intuitive, elegant interfaces, and this is why they crash.

vietkillerz
vietkillerz

The worse is sometimes when these frustrations occur at the worse possible moments. I'm talking about when deadlines rush up on you ... not that I procrastinated or anything ... and many other projects are in different stages of development ... all due to technical problems ... arrgghh

smankinson
smankinson

I have so many workarounds that I could claim that I am constantly in the 'technical frustrations' stage!

brucelofland
brucelofland

I have encountered this situation more often than I would like. Some of my biggest challenges were writing code for "microcomputers" back in the 80's. It is a result of being on the bleeding edge. The technologies are not mature enough to avoid this. The software development field moves very fast and is competitive, so products are released buggy and sometimes without much design effort. If a software developer does not stay near this bleeding edge, they risk becoming less valuable. It feeds on itself. Learning a new development language or platform is easy, learning all the bugs with it is hard. http://blog.pmtechnix.com

mattohare
mattohare

It only seems often to me, because it often takes a lot of time. I do notice much of the time really is fun development.

apotheon
apotheon

I rarely run into the kinds of problems described in the article. Of course, most of the reason for that is the simple fact that I rarely use the kinds of tools that have those problems. My "IDE" is several terminal emulators, one of which is running Vim for my primary editor. I use command-line interfaces for version control, file browsing, test suite execution, and file transfers. I even tend to work more often on projects where data stored in ASCII formats is at least as suitable to the task at hand as an RDBMS, so technical issues with RDBMSes are rare -- but when I do use an RDBMS, I tend to use something that isn't tightly integrated with the OS, and stick more often to CLI tools than GUI tools when I need to deal with database management. Obviously, this sort of tool selection is not much of an option for some people, such as those who are specifically employed to write GUI-driven ERM systems with the .NET framework. Still, if you have the opportunity to simplify your development environment, you may discover two things: 1. You don't always need all those fancy tools which, surprisingly, can actually get in the way even when they aren't broken. 2. Your technical problems that hold up development may quickly begin to melt away. The closest thing I get to such technical problems is, from time to time, missing documentation for a library.

apotheon
apotheon

Common? Yeah, I guess so. Something that should be expected? No. There's a difference between having a job that's challenging, and having a job where all your tools are broken.

Justin James
Justin James

4GLs are the answer to that, but in large part, they've been a disaster. As a result, the entire field has gotten a bad rap. That being said, I think the current generation of products has a lot of potential, and in the case of at least one product that I've used, a lot of actual usefulness. J.Ja

Justin James
Justin James

Try developing .NET code in Notepad++. I don't get to pick and choose the techs I work with. And my frustrations are hardly limited to VS, which usually treats me quite well. My current pain is actually with MS CRM... don't get me started on that app! And for the record, I've spent an awful like of time developing in plain text editors, and it would take a LOT to make me go back. Debugging is a good example why... if you really think that the problems of a "bloated IDE" offset the debugging advantages compared to a plain text editor, then you are wrong! J.Ja

paper.bill
paper.bill

Back in the 80's we wrote our own code at the lowest levels. When a component didn't function as we expected, we looked under the bonnet. We can't do that any more and so we feel disempowered; that's frustrating.

cougar.b
cougar.b

I agree with you, and the quality and availability of the documentation is frequently the deciding factor for me about what I choose to use. I've been programming quite intensely for over a year in PHP, so I'm relatively a newby compared to others in this forum. I have minor experience programming in VB, Java, and C#, but my real experience is as a Senior Technical Writer in a large Java house a number of years ago. I may have just found what my personal programming home is, but in PHP, I'm not experiencing the technical frustrations I experienced in the other environments. However, my personal soapbox is that many, if not most, technical frustrations could have been avoided if the developers had been more careful about commenting their code, which is, of course, the foundation of any good API, and many other types of end product documentation. As a tech writer, I worked to create printed APIs that were directly read out of the Javadocs (all 1000 pages), which meant that my job as the writer was to make sure that the in-code comments were worthy of publication. This meant that the developers who used our product always had all of the information that they needed without consulting anything but the code. For my own work today, I treat the comments sections of the code as a place to blog about all of my brainstorms, frustrations, and plans, as well as to document specific functionality. When I'm done, then I'll go back and clean up the comments, but you can be sure that they will be more useful and more complete than they would be if I were to treat them as an after-the-fact chore. I consider the comments sections to be among my most important development tools--more important than the IDE I use--because of how extensively I use them to manage my thinking process. What this means is that future users of my code will not only experience fewer technical frustrations than they would otherwise, but if bugs do show up, they'll be easier to fix. In terms of docs, more is definitely better during the analysis, brainstorming, development, and initial testing phases, because when you clean up your comments at the end, you get much better quality.

scott
scott

I just lost 2 weeks of work because of a deadlock that I figured was in my code. The issue would only come up after about 2 days of running the software in normal mode, I was able to tweak things to make the problem happen after 8 hours. After trying this and that, came to the conclusion it was a 3rd party module that was causing the problem. I'm frustrated over the lost time, mainly because it's not my code doing it. If it was my issue, then I would be to blame myself and be able to move on better. Now I get the joy of upgrading existing systems in the field to not use this module. Joy!

Justin James
Justin James

For my "day job" I develop against the Microsoft stack, and it's a nightmare. In and of itself, the development tools are fine (excluding the bizarre VS2010 bug I wrote about recently) and don't get in my way. They actually help a LOT, especially VS2010 with its parallel debugger, IntelliTrace, and general improvements. VS2008 + ReSharper was a good combo too (I've got a ReSharper 5 license eventually coming to me as a "speaking gift" at a user group recently, so I can use it with VS2010). If I were just writing plain old C# code, perhaps as a WCF Web service, WinForms, or console, I'd be happy as a pig in mud. It's when I interface with the stuff I'm working with... Microsoft Exchange, Microsoft CRM... that things go horribly, horribly wrong. ASP.NET (at least with Web Forms, I haven't tried MVC yes) makes me want to defenestrate myself. Exchange itself is fine, but the only book out there with information on it seems to be wrong (and it was only 1 chapter dealing with the Web services). MS CRM is n absolute travesty. Worst application I have ever dealt with. I could write a book called "why MS CRM should never be used". The funny thing is, for my personal work, I've been using Agile Platform. By all measures, it *should* be a total disaster. It's a very visual tool. It hooks deeply into the Microsoft stack. It's a 4GL. Every single "this tool is going to make me miserable" red flag is there... yet it works fabulously well and I love it to pieces. It's inexplicable. I'm supposed to hate the tool for taking control away from me, and I end up loving it for allowing me to not worrying about the millions of details I hate worrying about. Right now, I'm integrating a CMS written in ASP.NET (Kentico) with Microsoft CRM, and I'm tearing my hair out with dippy details. But the Rat Catcher project is just rocking along. I'm going to try Alpha Five for a small project very soon (I'm ready to take a minor break from Rat Catcher), and I have a feeling that it too will be good (I've seen a zillion great demos of it, just haven't had time to try it), despite it being a 4GL with all of the red flags that I saw in Agile Platform before I tried it. J.Ja

Osiyo53
Osiyo53

Are the tools truly broken? Or simply not perfect and not capable of handling every possible way they might be used that ANYONE may dream up, and not possessed of every feature ANYONE might desire them to have? What guru of tool builders is building your tools? Undoubtedly I don't see or face precisely the same issues you and Justin do. Since I'm currently in a rather specialized end of the business. But I'm far from newbie to computer systems, OS's, programming languages, etc. Have been dealing with them since the old main frame days of the 1960's. I've never seen an OS, driver (hardware or software), programming language, IDE for a programming language, add-on library for a programming language, etc etc that was perfect, bug free, capable of doing everything one might dream up for it to do in exactly the same way yah might want to do it every time with ease and simplicity. And I don't care if we're talking about one of the many incarnations of DOS, CPM, Windows, Unix, Linux, or whatever. Or who made what tools. As long as I've been in the biz, one has always needed to use supplementary tools (bought or self created), to get around inefficiencies or omissions or plain bugs in whatever major tool one was using. Needed to figure out some work around for something that didn't work as expected or desired. Needed to keep notes as concerns the Oops and gotchas that everything I've ever seen has had buried somewhere within it. Geez, at home where I do all my own repairs, modifications, and additions to house and property and everything in and on them ... I've never found a single hammer that'll handle every task I might need of it. Or s single wrench. Etc. And I'd hazard to say that it's likely I have a wider selection of such things than most hardware stores. Still and yet, I routinely come across situations where I need to improvise, kludge together an imperfect but at least workable solution where no off the shelf tool would adequately handle the situation. Or use a tool for other than its original intended design purpose. Etc. In my professional work, I've never seen the perfect, does anything yah can dream up the way yah want it to do it, bug free anything. Ever. In fact there are several special interest forums specifically set up for people who work with the things I do whose major purpose and goal is to share ideas, solutions, workarounds, and so forth. And its pretty common for me to call up, or send email to, a maker of one of the software tools I use to report something along the lines of, "Hey, your software has this or that bug in this regard." And for me to get a response like, "Yeah, we know. It was missed during the initial testing and the first couple years of field usage. We're working on it, but the remedy will take some time to correct. In the mean time use this work-around ...." Or for me to report a "bug" or feature omission just to have them come back with, "Yep, that's a new one to us. Yours is the first report of this. As near as we can determine you are the only one trying to do that in precisely that way. Why?" To which I might answer that in our estimate, the way we're trying to do it has this or that superior advantage. Often as not, the answer I get to this is something like, "Okay, but your way would require considerable modification to our product. An under taking we're not likely to consider until and unless we have a significant number of users demanding it." So on and so forth. And no, I'm not even talking MS products. Nor solely talking about items running under Windows. Some run under a version of Linux, some under a proprietary OS. Etc. All over the map. What software tool out there is there that doesn't have bugs, glitches, unexpected behavior under certain conditions or usage, limitations, omissions, is capable of doing every possible thing yah might dream up to demand of it, etc? Just curious. I've never seen such. Of course, some things get more frustrating than others. In one of the areas in which I do development/programming a particular programming development environment is used. (By thousands who do the same sort of work I do) Very capable, very flexible, very extensible. But because it is all those things, developing in it can be deviously complicated and frustrating at times. Friggin user guides consist of thousands of pages, broken up into several volumes. And that just covers the bare basics. Just ... barely ... enough to get yah started doing a few very basic and simple things. Not even close to all you'll need to know and figure out in order to produce a final product anyone would pay you for. Revisions, additions, bug fixes, suggested work arounds for "bugs" that aren't gonna get fixed any time soon, etc occur often enough and in enough quantity to make a person cry, in frustration at trying to stay current. And then, since this "system" is supposed to allow one to interface with and exchange data with an almost endless list of proprietary and open "other" apps and such, via any one of numerous sorts of network arrangements and protocols (name virtually any you've ever heard of, its probably on the list) things get even a bit more complicated. Because the customers we're developing for all have their own ideas as to what they want and expect, how it should be presented, on what kind of hardware and network, connecting with and exchanging data with ... Who the heck knows what? (every single job is different) ... you also need to become familiar with and have the additional documentation/help files for an almost endless variety browsers, office apps, databases, and so forth ... and VERSION counts. Anyway, when developing for that system of interfacing with and integrating disparate and widely differing items, the usual thing is for us to spend maybe 10% of our time on 95% of the project, and 90% of our time chasing down unexpected behaviors, quirks, results, bugs, or what have you and figuring out "workarounds" for the remaining 5%. And as we do contract work, using working with a fixed bid price, one can grow grey hair in a hurry, take up drinking an extra adult beverage or two after work, become subject to nervous break downs or high blood pressure, etc. All common symptoms amongst our developers. That and a driving need, urge, etc to spend considerable personal time hanging around those special interest groups I mentioned, trying to stay current, locate someone who knows how to do whatever that a customer demands and expects which isn't in those thousands of pages of help files. Or at least you and a hundred others you've asked doing know where to find it if it is in there. Fortunately, while it may take a few days for the ONE guy who knows or has figured out a workaround to read that particular request for help ... someone usually comes up with something that'll work. I almost certainly don't work with the same tools you guys do, but the kind of things you're complaining about is pretty much "business as normal" in my world. In my world, you pretty much are having a good day if things are only SNAFU. (Situation Normal, All F*cked Up) And things aren't just all that bad when it gets to TARFU (Things Are REALLY F*cked Up). You only begin to really sweat and wish for a bit of relief at a local watering hole once the situation reaches total FUBAR (F*cked Up Beyond Any Repair). For some of us, we don't really get all that excited even when FUBAR is reached. BTDT too many times. It becomes almost like visiting an old friend. Named Murphy.

Justin James
Justin James

I don't get paid to solve the problems with the tools and systems that are supposed to allow me to deliver solutions. I get paid to deliver solutions. If the tools weren't such a disaster, we'd actually have MORE job security. Why? * Few things look worse than blaming tools/systems for the lack of results, even if it's true. * Better productivity for FTE's means that projects get more ROI, therefore you can either work fewer hours (no more death marches, hooray!) or take on more projects, saving the company money. Either way, it's good for you. * A consultant who can do it quicker is free to charge more money per hour, and either work fewer hours or make more money. And their clients win too. A consultant charging $100/hour for 10 hours of work is a better bargain than one charging $75/hour for 20 hours of work, AND the client gets their solution faster. J.Ja

apotheon
apotheon

There are other ways to get similar benefits for debugging than using an IDE -- ways that I prefer. Of course, that sort of tool support doesn't exist for .NET languages, because the One True Way to develop with the .NET framework is with Visual Studio, as you pointed out.

CRMatthews
CRMatthews

I worked on NCR mainframes from the late 70's to the late 90's. When something didn't work, you could always get a memory dump and figure out what the problem was. Now, with PCs and Windows, everything is so big (and bloated) it is hard to follow. We used to be able to get a lot done on a system with not a lot of horsepower and 16k of memory. Now, you need huge amounts of memory and CPU power to get anything done.

Justin James
Justin James

Microsoft CRM's email template system does not allow you to edit the HTML for an email template. So the "solution" is to *not* do things the "right way" and use the CRM system's placeholders, but to kludge your own placeholder system and pre-process the email. J.Ja

smithkl42
smithkl42

This reminds me of Joel Spolsky's description of the "two camps" inside Microsoft (http://www.joelonsoftware.com/articles/APIWar.html): the Raymond Chen camp and the MSDN Magazine camp. One is minimalistic and focused on backwards-compatibility; one is maximalistic and focused on new features. It's hard to know which approach is "right", but we'd probably make very little progress as an industry if there weren't forces pulling us in both directions.

Justin James
Justin James

I'm not talking about "glitches" or "bugs". I agree, they occur in everything and as long as the bug rate isn't unusually high, it's not that big of a deal. I'm talking about fundamental screw ups. Here's another example from my daily work life, again, interfacing with Microsoft CRM. To hook into certain events you need to write a "plugin" which has a fairly rigid structure around it. Fair enough, you can't expect that you can just write a piece of code capturing an even, upload the DLL, and somehow the system will recognize it, not in a static language at least (in a dynamic language with eval.(), this is a cinch, of course). To use the plugin, you need to use a standard library which has inherent knowledge of the entities in CRM. The problem is, the entities in CRM are customizable! In any other piece of code accessing CRM, you don't use a static reference to the entities, you use references to a Web service, so as you make changes, an update to the WSDL makes them visible to you in the object tree. But with the plugins, that won't work, because the existing entity objects (which you will *have* to use somewhere to work with the plugin structure) belong to one namespace and have no awareness of the entities in the Web reference. Sure, you can add the Web reference, but there is no way to cast from the Web reference to the plugin SDK's version, or vice versa. So, if you want to work with your custom entities, your choice are: * Set up a parallel set of references and hope they never need to cross paths. * Set up a parallel set of references and write a ton of boilerplate casting code that copies the attributes back and forth. * Use the "dynamic queries"... are insanely clumsy, instead, say, entity.creationtime you do entity.GetDateTimeValue("creationtime"). So you totally break the object model. This is the kind of "broken" that I'm talking about. Sure, some of it is bugs too (like the Visual Studio problem I recently had that cost me a lot of time), but over all, it is fundamental, stupid design decisions that make me spend more time finding workaround than delivering solutions. Ugh! J.Ja

apotheon
apotheon

I'm not sure which would be worse. I have never allowed myself to get deeply enough mired in these two technology ecosystems to be able to form a solid opinion on that score. As a very uncommon user of them, however, they each are (frequently and deeply) broken in their own special ways.

Justin James
Justin James

... is that the consultant who has handed this off to me has been doing it for so long, it's "normal" to him. In fact, he's used MS CRM as the foundation for other applications. If working with a product this clumsy ever becomes "normal" in my mind, I want you to *insist* that the doctors run a full battery of blood tests, concussion tests, MRIs, body scans, etc. to find out what is wrong with me. And not only do I agree about the Java comparison, I think the Java world is even worse. J.Ja

apotheon
apotheon

I would think that MS Windows developers should make twice as much money as they do, just to make up for the aggravation of the technologies they use. Same for Java developers, frankly.

Justin James
Justin James

"I really have a difficult time figuring out how developers put up with this stuff." I look at pictures of my kid to remind me why I do this. The only thing keeping me sane on this particular project is that the project is nearly wrapped up. Don't even get me started on the CMS. The CMS itself uses an architecture that I never liked, and the developers had to mash the .NET AJAX Control Toolkit and jQuery to make it do certain things in conjunction with the CMS... and I'm trying to bridge the gap with my API to MS CRM. I should maintain copies of this thread so when my kid is old enough to understand, he'll know what I did for him... I'd tell you about tonight's mess, but your reaction would need to be "I really have a difficult time figuring out how system administrators put up with this stuff" since I was wearing my sys admin hat for it... J.Ja

apotheon
apotheon

I really have a difficult time figuring out how developers put up with this stuff.