A place to discuss Joel on Software. Now closed.
This community works best when people use their real names. Please register for a free account.
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot
The Old Forum
Albert D. Kallal
I used to like writing software and reading up on new things.
For the past 6 months I have been occupied at work refactoring legacy code so it doesn't fall apart, fixing bugs in my boss's VBA code and rewriting pieces of applications that only barely just worked by client code having to explicitly work around the deficiences.
The only work I did this year I could at least in some small way be proud of has been trashed by the company as they effectively burned the money it generated the first time around and the second time around they couldn't be bothered to get back to the client to arrange further work. As such I've done decent work but nobody in my workplace has any sense to realise it.
I feel drained. What happened? Software is supposed to be creative and fun.
How many people feel the same as me?
The joy of creation of a quality product is one of the keys to why making software is fun for me.
When I am 'stuck' in the position of upgrading some-body else's code, or I am 'stuck' with a low-quality design, there is very little productive I can do. Yet I am supposed to "make it work". The result is a convoluted, painfull ball of wax. It is hard to test, and has lots of hidden gotcha's which bite you when you least expect.
When I simply have to deliver a low-quality product, because that's all the situation allows, then it is no longer fun. In fact it can become a very painful and grinding process.
This is the difference between being a carver of wood, versus a cutter of fire-wood. That wouldn't be a problem if the customer wanted a cord of wood. It's a problem when the customer will use your beautiful sculpture as PART of his cord of wood. It's also a problem if he complains your cord of wood looks NOTHING like the sculpture he really wanted.
Wednesday, December 15, 2004
I hear you. I am stuck on a contract to hold the old system together for a company as it converts to its new one. They told me upfront that we know all of our code is a stinking pile, we dont want you to fix it just keep adding bubble gum and tape till we convert.
I guess I am getting my fun agian for coding by studing for the mcad tests at night. I do have to admit that I am glad that I am only contracting here. They have the same substandard coders that created the current pile designing and coding the new system. I use design to mean figure out the requirements as they are writing and shoo horn things in as they appear by magic as needed.
Well I am in the same "boat". However, the project I took over, I simply re-wrote...quickly. I used the basic logic and got the old code under control, you have to "divide and conquer". Then through testing and pressing the issue "we can't do that". I was able to add enhancements and fix the "bugs". I made each enhancement and bug fix to be like a new project. Yeah maybe I am bragging a little here, but, everyone was impressed when the error rate for this project went from 90%+ to 90%+ success rate. The underlying database maybe a mess but working through each piece is exciting and a learning opportunity.
Now there is all kinds of "things" they want done. :) It has gone from boring to really exciting! I have the "crappy code" under control that now it is so easy and fun to port it to other systems and languages (i.e. pl/sql and vb.net). In fact they are having me teach junior programmers "programming", probably a mistake.
They did tell me not to "waste time" modifying the code just "fix problems". I did both and I did not "waste time". Using Joel's insights and thought provoking discussions has contributed to me being a "mature" programmer. I could complain about “how things are done" here but why? I just did the coding and moved on. I was surprised what has happened! :)
Heh - I wish I could do what you describe! But there's more than one coder working on it, and they are seriously change resistant (anti-source control anyone?) It's also a large project - I don't know how many hundreds of thousands of lines it currently is, but it's a few I think. Of course, I think I could refactor it to about a third of it's current size, but... Ah well.
People, here is a samurai medicine for your "funless" software development:
For windows developers, take the shortcut: http://rubyforge.org/frs/?group_id=167
For the best MVC web framework you'll ever see in any platform: http://www.rubyonrails.org/
Make sure you watch the short videos of this one and I promise you: you will get back the fun in your programming lives.
But, be warned: you probably will never want to go back to any .NET, J2EE, C++, etc.
Run screaming. Now.
Any shop which can't at least figure out how to muddle through CVS is so incompetent that there's no hope.
The only way you can keep your sanity in such an environment is if you can persuade the team to start using version control, bug trackers, and so on.
J. Random Hacker
Wednesday, December 15, 2004
You don't think you can find some zen satisfaction in slowly and certainly teazing out the knotts and bad code and refactoring it into shape?
It's not the most fun, but it can be kind of restful sometimes.
Wednesday, December 15, 2004
In reply to the last post, I did not find any satisfaction becauase:
1) I virtually rewrote the first disaster project I was given. The last thing I heard about it was that the client is pushing it into production. When they made comments about the work I did a few months ago, they only managed to find one or two very minor bugs that took me minutes to fix. Really minor things like one duplicated checkbox on a form.
There is a very tiny bit of satisfaction from that. BUT my current company (NOTE NOT THE CLIENT) lost interest in the project and kept the client hanging on too long about a maintainance contract. As a result the client walked, asked for the source code and has now awarded from work on the source code I wrote to another company! After all my work, the company has now lost a revenue stream for a very wealthy client.
2) The second disaster project I was given was written by a director. I said in the beginning we should just take the bits of the project that work rather than incremently fixing bugs. The fact is the project is bad not because of all the bugs but for other reasons.
In places it tries to do things that will never work correctly and aren't really needed for the aims of the program. As my boss rambles on about how proud he is of his work I don't really have free reign to refactor it and cut the crazy bits out.
For example one thing that he did was to read in Excel formulae and convert cell references into the constants they refers to. Then he copies the new formulae into other cells. Trouble is it is now a different formuale and for it to work properly the cell references have to be remapped. Unfortunately they are now constants. So it breaks. The whole thing is flawed and you can't incremently fix something like that.
Another thing he did was to have a global VBA Collection and bung whole loads of things in. a) VBA's Collection is not hashed (unlike VBA dictionary) and so lookup is slow. b) As he puts anything he wants in it, it will just lead to bugs as there will be clashes. He rambles on about how proud he is of his "caching" scheme and so I can't really replace it. Quite why the application needs caching here I don't know. Are Excel object model calls to get things out of cells really so slow they need to be cached? No. Quite frankly the cache probably slows the whole thing down.
Yes. I am currently staying sane by playing a slow and arduous political game of gently prodding development practices into place. Oddly enough, the hard sells seem to be the easy ones. Source control has taken ages to even get experiments done with (all Perl source is now under SCM - the first battle of the war), but using Reddick VBA notation (essentially Hungarian) was an easy one - my boss thought it was a great idea straight away. Whether it'll get done is another matter - hence the attrition part of my war.
I've heard the same complaints since the 1970's. A pro does the dirty boring details that are required to ship. An amateur just does the neat fun stuff and moves on.
No, I'm not that old, I just started young.
Thursday, December 16, 2004
Writing software has usually been fun for me. I wrote a lot of code for open-source projects, either ones I initiated, or others I joined and it was very enjoying. The code I worked against was of relatively high quality (or at the very least at least worked the way it should), and whether I was refactoring, adding new features, or fixing bugs, it was quite enjoying.
Recently I spent some time heavily refactoring, re-organizing and writing tests for a Perl module I wrote. Initially I based it on a different module someone wrote, but now, I wrote my own code to do the same thing with much fewer hassles, and then continued to improve it even more. I'm not done yet, and it took me a while, but now my code is much better.
In some of my workplaces, coding was a lot of fun as well.
I can understand why in certain situations coding will not be fun. Recently I joined a workplace, in which I was given a task to automate a PowerBuilder-based Hebrew-supporting applications using the Win32::GuiTest Perl Module. The application misbehaved and it took me a long time to get it to do anything useful using the module. Even WinSpy/Spy++ have problems understanding what went there. I spent several days writing less than a 100 lines of Perl code, and it still had a lot of kludges and workarounds, which I couldn't determine why they were required, except that they made it work. I didn't like it one bit.
Eventually, I was fired from this job after a few days of working there, but I was glad that I did.
Coding is fun for many people as long as what they are doing is fun. I'm pretty sure, you can find a codebase that working on it will be fun for you. Maybe not at your current job, but certainly somewhere else.
Thursday, December 16, 2004
Work isn't always fun. This is a fact of life, if work was always fun nobody would call it work and you would have a hard time convincing people to give you $xx per hour, after all you'd probably just want to do it. Part of the expectation in a job is that you'll toil through the difficult times and solve problems and get things done even if it "sucks", or it's not the most elegant solution, etc. However programming comes in a variety of flavors, and one of them is maintenance, this is basically a process of picking through legacy code and resolving issues without causing additional breaking changes. Many times in this type of position you are privy to insights of the worst kind about the people and the decisions they made which got the product to market, sometimes they were well intentioned people with bad ideas or greedy people who pushed it out the door, either way you're peering at the underbelly and it's not usually pretty. Often maintenance includes the development of additional features with the constraint that it needs to remain compatible with the current product and can not require additional libraries, frameworks, technologies... This is a small glade in an otherwise dense forest where for a moment you are allowed limited creativity, expect that you will soon return to the normal routine of fixing bugs that someone fresh out of college upstairs is making for you using the latests tools and technologies. Maintenance takes a special type of person, it is not as exciting nor as appreciated and is not very visible, but in the end it is necessary and therefore typically a very secure position (even though you may not be asked to make powerpoint presentations about the latest bug you fixed, someone up in management knows that you're the reason their $16,000,000 per year revenue stream continues to exist). Software is a difficult profession, I worked on a variety of Web Sites/Applications which no longer exist, some which never even got completed, there are a couple of companies that still limp along but have never found that gold nugget they felt entitled too. There are a lot of programmers out in the market place, and the tools and framework technologies lower the bar in terms of technical expertise, sometimes companies care only about your experience with tools (trust me I live in a WSAD market, how is knowing WSAD more important than knowing J2EE?).
It sounds like you should find a new job, if your company is making "bad" decisions then you have two choices, you can confront the people making those decisions and exert your own influence in the company to encourage the company in a better direction or you can leave. Before you leave try to exert your influence, talk to people, communicate, knock on doors, find out how things are getting done, who and why, if you are told to go back to your cube and fix bugs then go back to your cube and pack your stuff. Sure not everyone can do this, you may have mortgage and a pregnant wife expecting twins, but if you don't and you can be flexible then be flexible, nobody can definitively say what happens after this lifetime so don't sit in your cube and work on code that causes you to feel morose or worse because you don't know what'll come next. If you feel that your company abandoned you, that they disenfranchised you by dumping off your work on the client you need to communicate that, maybe the client would hire you on, maybe your company could make that arrangement. If you are unsatisfied in your job speak-up, sitting back and letting things happen, taking the attitude that "I'm not going to stir the pot" or "nobody will listen to me anyway" is only going to leave you where you are.
Maintenance programmers don't mind, they don't mind that they aren't famous, they don't mind that nobody from marketing has come and asked them to write a blog, they don't mind that so-and-so who just got hired makes more money even though the code so-and-so writes is riddled with bugs, that's one of their traits which makes them so damn good and reliable, they don't mind they just fix the bugs.
Anyhow I can't emphasize enough how important enough it is to communicate, even if it gets you fired, because by attempting to have the conversation you make an effort to address and improve your situation, if you just sit and mope then when it comes times for raises, or worse layoffs where do you expect you'll be?
Sorry to be so verbose, this whole topic set me off so I'll just place an article on my blog:
Thursday, December 16, 2004
I've worked at 5 different companies over a decade as a developer (two of them occupied the majority of this time). Anyway, over the years I found out that work environment is very important. What I mean by environment is the people, the organizational atmosphere and how management treats it's staff (actually, I found that management is the prime factor that affects the quality of the work environment).
My first big job had plenty of fun coding opportunities. But the company's proceeded by the seat of the boss's pants. The boss was not a particular stable person. So, the fun coding was often interupted by paranoid speachs, freak-out sessions, guilt-trips, etc.. you name it we got it. I left the job so screwed up and mad. For three years, I tried to get the boss to instill a process (bug tracking and proper project management), a week before I announced that I was leaving, he brought me in his office to tell me that all these years I was right. A few months later he had a nervous break down and the company went down the tubes.
This first example is a pretty extreme example, but I found that many places operates in a similar way (but perhaps a little less crazy).
At the moment, until my job gets out-sourced in the new year, I work in a pretty good corporate environment. The coding is occasionaly fun (get to try new technology (new to me anyway)). The politics can be a little annoying, but the work environment is positive and management values us. I must admit the dullness of the work affects morale, I need to do stuff in my own time to stay interested.
The ideal would be to find a small place with good management.
Friday, December 17, 2004
<I>I've heard the same complaints since the 1970's. A pro does the dirty boring details that are required to ship. An amateur just does the neat fun stuff and moves on.</i><Br><br>
So by your definition John Carmack is an amateur and Robert Duffy or whoever cleans up John's code for release is the pro?
Friday, December 17, 2004
"The joy of creation of a quality product is one of the keys to why making software is fun for me."
Same here. The quality and design of the project I'm stuck on are so hopelessly bad that I sometimes find it hard to sleep at night. Software construction is only fun when you can be proud of what you're building.
Sleepless at Night
Friday, December 17, 2004
As the industry has matured over the last 10 years the 'fun' has drained out of it. The fun came out of the newness, which ccouldn't last forever. The platforms, languages and tools aren't really changing much today, just evolving incrementally.
And the work has been corporatized - the Process people have gained control. Arguing with them is like trying to debate a Creationist - you end up tied in knots.
I feel lucky to have been in the business during the 70s, 80s and early 90s when the new, fun stuff was going on and I have no regrets.
Grok - to every rule, there are exceptions. ;-)
Saturday, December 18, 2004
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz