Coffeehouse Thread

25 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Code you write, are you proud?

Back to Forum: Coffeehouse
  • User profile image
    vesuvius

    There is a wealth of project management practices like SCRUM, TDD, Agile (which SCRUM is) and so on, but the focus is always on doing something yesterday. A lot of the code that I see nowadays, is written to solve a problem and not necessarily for maintainability.

     

    In almost all cases I start off blaming the poor calibre of developer that wrote the code, but inevitably realise that they were given 10 minutes to write a complicated module, hence why the code is the way it is.

     

    Some developers check code in every once in a while that works, and generally needs minor bug fixes if any at all, but the agile process says check code in often. I know developers that say they have fixed an issue, but for several weeks later they are still updating the code they wrote - was the problem really ever fixed, or was it brushed underneath the carpet?

     

    Obviously larger companies like Microsoft are advertised as cultivating environments where developers can produce the highest quality code, but there are deadlines there as well.

     

    I also find the a lot of places don't really understand the management systems they are employing, take SCRUM for instance which comes from a sport called Rugby. It is more about management having a daily meeting so they can appraise their boss (micro management, that's what it is) that they spoke with the developement team and are at state x, y or z, but it is rarely ever about teamwork. The only team thing that happens is that people are in the same boardroom at the same time.

  • User profile image
    ManipUni

    My code isn't great but I think you are giving Microsoft far too much credit - they write some very bad code.

  • User profile image
    Dr Herbie

    Most of the code I write, I'm not proud of; it gets the job done and it's (relatively) defect free, but the system I work with is close to being a big ball of mud.  It's very hard to write elegant code when most of what you do is making changes to a BBoM under time pressure.

     

    That said, I have started to spend a bit more time implementing the "Boy Scout Principle" to make minor improvements to any code I touch.

     

    My main frustration at the moment is wanting to re-architect code for which there is no real business case to re-architect.

     

    Herbie

     

  • User profile image
    CKurt

    I'm more proud if I solve an architectural problem or find a way to build objects and classes in a way that is super efficient and logical.

     

    I do (like many others) always feel when a project is finnished i would have done it somewhat different. Because you can always 'calculate' the unexpected, but you never really know what you might have missed.

  • User profile image
    sysrpl

    Yes

    and

    Yes

    and

    Yes

    and

    Yes

    and

    Yes

    ....

  • User profile image
    exoteric

    I think you are right about your sentiment here, vesuvius. The software world is a world of fashion. Trends come and go, be it project management or ways of programming. Right now the trend is a very factory-like approach that appears to have been proven succesful in practice but it probably has its own set of costs and in time I could see a counter-trend arising.

     

    In my oppinion SCRUM lends itself less to creative development because everything is focused on "getting the job done in time" and less about how the job is done - it's purely about project management in a way and less about overarching architechtural concerns. The short-term progress is measurable and easily defensible whereas the possible costs in terms of hacks and unsound architechture is something that does not show directly, instead it shows up in how long it takes to solve problems in the system over time. At least it requires some backbone to make sure short-term commercial concerns do not create short-term solutions.

     

    It's clear that it should be a goal of every developer to be proud of his/her code. Sometimes short-term concerns just make that kind of code impossible.

     

    To explain to the customer: it would really help out if we refactored this part of your system. But what's the business value of refactoring? Yes, we'll be able to develop in this part of the system faster in the future and you'll have less bugs...

  • User profile image
    Bass

    If I'm not proud of the code I write, I don't check it in to the central repository. It's as easy as that.

  • User profile image
    Bas

    I'm occasionally proud of the code I write at home, for hobby stuff. I couldn't care less about the code I check in at work: as long as it does the job and isn't a disaster to maintain, it gets checked in. I haven't got the time nor the motivation to write amazing code at work.

  • User profile image
    spivonious

    I'm proud of code I write when it's new project. Maintenance code on someone else's project is quick and dirty, and doesn't really reflect my standards.

  • User profile image
    Ray7

    Bas said:

    I'm occasionally proud of the code I write at home, for hobby stuff. I couldn't care less about the code I check in at work: as long as it does the job and isn't a disaster to maintain, it gets checked in. I haven't got the time nor the motivation to write amazing code at work.

    Really? Don't you like your job or something?

  • User profile image
    Bas

    Ray7 said:
    Bas said:
    *snip*

    Really? Don't you like your job or something?

    That too, but even if I did, I don't see why I'd go through the effort of writing amazing code there. There's absolutely nothing in it for me, so why put in the work if there's no return?

     

    Basically it's like that scene from Office Space.

  • User profile image
    figuerres

    well for me it covers a range of things....

     

    some code i am very pleased with...

    but some times it's "Make it work" stuff thats boring and not very much to look at.

     

    there is a fair amounbt of code i *WISH* i could go back and re-do but when the list of things the client wants keeps growing faster than i can clear it well..... if it works then move on to item #576 and #577 ...

    this is the difference between a hobby or an academic world... they do not care if it's elegant and well factored etc.... they care that they make money first. the they get the features second, that it's fast and then if we have time comes other things.

     

    generally i can get things at least "OK" but not great.

     

  • User profile image
    cheong

    spivonious said:

    I'm proud of code I write when it's new project. Maintenance code on someone else's project is quick and dirty, and doesn't really reflect my standards.

    On the other hand, I'm proud if I can get some nasty bug fixed without doing much harm to overall code structure. Wink

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    JoshRoss

    I believe in continuous improvement. For me, part of that involves reviewing old code; looking for new bugs or more elegant ways of solving a problem. When I have code that repeatedly fails to bear bugs or is unable to be rewritten in a desirable way, I feel a little pride.

     

    -Josh

  • User profile image
    punkouter

    Currently, I'm the lead developer of a project. But my project ended it's development phase a couple of months ago and right now we're at maintainance phase. With all the vendors out of my project, I'm left with maintaining the whole software alone.

     

    When the project was in development, I was the lead developer, architect and manager. These overlapping responsibilities makes it hard for me to monitor and to be too much involved in the development. Instead I was focusing on some of the critical module architectures, the management stuffs, such as resource planning, meetings, getting people to daily meetings, discussing priorities with users, etc (yes we are (try) using scrum). I found that scrum actually makes developers and users to understand each other better and  we have very good productivity and flexibilities compared to other teams. We don't work long hours, yet the users are very satisfied with our progress.

     

    However, after the project turns to maintenance phase, I found that there's a lot of things that are 'not as good as I hoped'. bad codes, bad designs are littering the software. I need to fix it, but who would ever give me the time to fix the whole software? So what do I do? Most of the times users demanded that bugs gets fixed immedietly. I can't rewrite the whole code/module in a limited amount of time, so I hack it. Now, this is the time where I'm not proud of my codes. But doing this means more hacks introduced everytime and the module will become more and more complex... given time it becomes very unmanageable.

     

    Usually when I feel that the module has too much mess, because of the complexity and because of the bugs it contains, I will raise the case to my users. I will usually demand to have the next development cycle focusing on fixing that module and that I need them to give me a full week or two. What I usually do, though, I don't fix the module, I trashed it, and recreate it from scratch. Now, that is when I'm proud of my codes.

     

    Of course not all users will immedietly give me the time for doing it. So, sometimes I need to work behind their backs. Working with the new implementation as I have the time. And when I finished with it, I demonstrated it to the users. They usually understand and accept the new implementations. That's also another win for me and when I think I produced codes that I'm proud of.

  • User profile image
    vesuvius

    JoshRoss said:

    I believe in continuous improvement. For me, part of that involves reviewing old code; looking for new bugs or more elegant ways of solving a problem. When I have code that repeatedly fails to bear bugs or is unable to be rewritten in a desirable way, I feel a little pride.

     

    -Josh

    I have code I wrote for a big supermarket 3 or 4 years ago that is still used daily . I wrote the application over 3 or 4 months with no time constraints, because the software had to work, and be error free. Any mistakes would result in  their orders system being out of step which was not acceptable.

     

    Given the same project today, someone would wet their finger with some spit, hold it up in the air to see what direction the wind is blowing, and shout 42. This project should take 42 days!

     

    I would probably attain some functionality by the time the 42 days was up, but I'd be overworked and overstressed, and hate the job I am doing. I am also beyond any doubt that the code would have needed several updates, that in the long run would add up to more time than I initially spent without the pandemonium of micro management making the project managers feel as if good work is being done.

     

    The long and the short of it is that project managers generally have a very short term view, and never ever factor in  having code that is of a high quality, and the benefits that gives. We have made advances in memory managed applications like Java and .NET, but C# isn't some magic programming language that makes everything easy. You can still create spaggetti applications as easily in .NET as C++ or VB6.

     

    In several years time, the focus on SCRUM and Dickensian style production of code that has become unmaintainable will leave people scratching their heads as to how they ever got into this mess? I already know of some people that are up sh** creek because their .NET code is not just in need of a refactor but a complete re-write [shudder]

     

    Programmmers are expensive for a reason, if you treat them like children, and if you start making them work in ways where they cannot practice the science of computing and the art of making things easy to understand, you end up with the worst of both worlds.

  • User profile image
    Blue Ink

    vesuvius said:
    JoshRoss said:
    *snip*

    I have code I wrote for a big supermarket 3 or 4 years ago that is still used daily . I wrote the application over 3 or 4 months with no time constraints, because the software had to work, and be error free. Any mistakes would result in  their orders system being out of step which was not acceptable.

     

    Given the same project today, someone would wet their finger with some spit, hold it up in the air to see what direction the wind is blowing, and shout 42. This project should take 42 days!

     

    I would probably attain some functionality by the time the 42 days was up, but I'd be overworked and overstressed, and hate the job I am doing. I am also beyond any doubt that the code would have needed several updates, that in the long run would add up to more time than I initially spent without the pandemonium of micro management making the project managers feel as if good work is being done.

     

    The long and the short of it is that project managers generally have a very short term view, and never ever factor in  having code that is of a high quality, and the benefits that gives. We have made advances in memory managed applications like Java and .NET, but C# isn't some magic programming language that makes everything easy. You can still create spaggetti applications as easily in .NET as C++ or VB6.

     

    In several years time, the focus on SCRUM and Dickensian style production of code that has become unmaintainable will leave people scratching their heads as to how they ever got into this mess? I already know of some people that are up sh** creek because their .NET code is not just in need of a refactor but a complete re-write [shudder]

     

    Programmmers are expensive for a reason, if you treat them like children, and if you start making them work in ways where they cannot practice the science of computing and the art of making things easy to understand, you end up with the worst of both worlds.

    Micromanagement is intrusive and stressful, but I came to accept it as a necessary evil. Developers (and I'm no exception) are bound to obsess on a single aspects of a product (be it an algorithm, an architecture, a framework, whatever), forgetful of when it's high time to call it good enough and start turning that shiny new toy into an actual product that customers would use and buy.

     

    Our quest for high quality code is just a step from wasting time: software always rotted, but nowadays it just rots faster as platforms evolve at breakneck speed. Take any C# code that was written pre-2005. Would you reuse it? Would you ship it now? No generics, no lambdas, no LINQ, no automatic properties, shiny custom controls that just don't look right in Windows 7 (and that aren't written in WPF anyway), use of deprecated classes and methods, code that duplicates what is now in the BCL. It was perfectly fine when it was written, now it's a stinking mess.

     

    Not to mention death by a thousand cuts, that is customers requiring a list of what they deem minor changes that get funded accordingly. You barely have the budget to make it work, never to make it right; that gets postponed to the next mythical big rewrite.

     

    Marketing might be at fault there, but the problem is that there aren't many customers who can understand the value of good code. (Or even bad code for that matter: when they ask that their order system can optionally work in the Mayan calendar, all they perceive is the new checkbox in the options dialog... "Oh, come on, how hard can it be?").

     

    This is not an apology for writing sloppy code, I still try hard to produce the best code that circumstances allow, and fight customers and marketing to get a little respect for quality. But I came to realize that I need someone, or a process, that keeps me close to reality. And, sad as it might sound, reality is that it's good enough that pays the bills.

  • User profile image
    vesuvius

    Blue Ink said:
    vesuvius said:
    *snip*

    Micromanagement is intrusive and stressful, but I came to accept it as a necessary evil. Developers (and I'm no exception) are bound to obsess on a single aspects of a product (be it an algorithm, an architecture, a framework, whatever), forgetful of when it's high time to call it good enough and start turning that shiny new toy into an actual product that customers would use and buy.

     

    Our quest for high quality code is just a step from wasting time: software always rotted, but nowadays it just rots faster as platforms evolve at breakneck speed. Take any C# code that was written pre-2005. Would you reuse it? Would you ship it now? No generics, no lambdas, no LINQ, no automatic properties, shiny custom controls that just don't look right in Windows 7 (and that aren't written in WPF anyway), use of deprecated classes and methods, code that duplicates what is now in the BCL. It was perfectly fine when it was written, now it's a stinking mess.

     

    Not to mention death by a thousand cuts, that is customers requiring a list of what they deem minor changes that get funded accordingly. You barely have the budget to make it work, never to make it right; that gets postponed to the next mythical big rewrite.

     

    Marketing might be at fault there, but the problem is that there aren't many customers who can understand the value of good code. (Or even bad code for that matter: when they ask that their order system can optionally work in the Mayan calendar, all they perceive is the new checkbox in the options dialog... "Oh, come on, how hard can it be?").

     

    This is not an apology for writing sloppy code, I still try hard to produce the best code that circumstances allow, and fight customers and marketing to get a little respect for quality. But I came to realize that I need someone, or a process, that keeps me close to reality. And, sad as it might sound, reality is that it's good enough that pays the bills.

    It is always rather gratifying when one receives such a well thought out, written and thought out response.

     

    I know that a lot of programmers are ill equipped to make the call as to whether a piece of code is sufficient as a solution though ineloquent. I know that there is an alarming lack of code reuse, but the proper answer I guess is that it depends. I recently worked on a project where it was all deadlines, everything had a stopwatch attached to it, and typically some of those estimations were widely wrong.

     

    I typically used several design patterns, and gained time by using things like enterprise library or various SDK's, where some people were re-inventing the wheel i.e. writing their own logging system or validation system, and dealing with the web of bugs they had just created. I was more productive than others because I was more experienced, and took the time to learn how to utilise various libraries that were tested, but if you have a team with young developers, and you are pointing a gun with a stopwatch to their head, without giving them room to develop and learn higher abstractions through the numerous API's, you end up with a cowboy project and cowboy developers.

     

    I appreciate and agree that micromanagement is an evil that is necessary, but you need to give younger developers the time and room to grow and learn better ways of doing things, and not always the cowboy way. In the long run it will always bite you back in the backside, as nobody seems to care about letting people develop.

     

    I know that I could pass MCTS in Winforms/WPF/WCF and the .NET base test, in a month, but presently, my inbox is full, and I cannot take the time off to improve myself. I enjoy learing new technologies, but timetables now are so crammed that you have to live for your occupation. That is what I despise, because for all intents and purposes, it is a way of ensuring that people progress at the slowest possible pace.

     

    A lot of the important architectural stuff I am good at I learnt when I was between jobs, I had several weeks to really drill down into SQL or WCF or whatever framework. YAGNI is a very good rule when coding, but there are technologies that are emerging now that will doubtless be beneficial. If everyone on my team had 2 weeks to learn parallel programming properly, we would produce software that will work very well, and get better as more cores become available. You try and explain the importance of parallel programming to a project manager. Thats when I think micromagement is wholly detrimental because in some ways it holds people and projects from progressing.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.