7 Replies - 1425 Views - Last Post: 31 August 2013 - 07:53 PM

#1 Ahhmyface  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 2
  • Joined: 29-August 13

Talking about bad code

Posted 29 August 2013 - 11:17 AM

I work at a startup, and I find myself craving structure. The CEO seems to have a blind spot when it comes to software processes. If this were a research company, we might be alright. We have a proven track record of creating prototypes, but when it comes to taking those prototypes and turning them into enterprise-grade products, it's a mystery to management. Everything is duct-taped together, demos are constantly faked, there are no coding standards, there's no code review, no refactoring. We've never had a software architecture meeting in the year I've worked here, and bug fixes are constantly pushed aside for new features. When a feature is developed, the programmer assigned to it has absolute power, and there are no checks or balances to ensure it's implemented "right". If it works, management is happy and we move on. It's not that they actively discourage good code, it's that they don't know it exists. Functionality is their entire world. Memory leaks are just bugs you fix when a customer is complaining.

I have no idea how to articulate the importance of these things to management. I can't even describe them to the other programmers. I lack the vocabulary. My concept of software done "right" and "wrong" has grown so organically that I completely lack verbal means to explain it to anyone else, including myself. Everyone can recite a big list of high level concepts, but to actively examine a (huge) piece of (complex) software and classify its mistakes is very difficult. It quickly devolves into "that part is confusing", "there must be a better way", or "wtf". I can't very well make a case to spend some time working to fix "crap that had to be redone". I can't very well approach another programmer and complain about his code if I can't justify it. There's a certain "je ne sais pas" to good and bad code alike that I can't put my finger on. And admittedly, some of it is beyond me. Should this be a script or a standalone executable? How do I take multi-tiered message oriented architecture and make it less like spaghetti? etc

I want to be the project lead, and I recognize that the ability to talk to other programmers and to management about code quality is necessary prerequisite. What can I do?

Is This A Good Question/Topic? 0
  • +

Replies To: Talking about bad code

#2 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 9585
  • View blog
  • Posts: 36,323
  • Joined: 12-June 08

Re: Talking about bad code

Posted 29 August 2013 - 11:26 AM

Quote

I want to be the project lead, and I recognize that the ability to talk to other programmers and to management about code quality is necessary prerequisite. What can I do?

Take a bunch of problem code, fix it, show them how well it works in comparison to production, and give a power point on what you did and why spending time to do it would be good.

Read up on effective project management and coding practices.. practice what you preach.. etc.

example:
http://www.amazon.co.../dp/0596517718/

In addition...

The alternative is to leave and find a place with a better culture... trying to create culture change without top level support is a hell of a fight.

Quote

My concept of software done "right" and "wrong" has grown so organically that I completely lack verbal means to explain it to anyone else, including myself.
...
I can't very well approach another programmer and complain about his code if I can't justify it. There's a certain "je ne sais pas" to good and bad code alike that I can't put my finger on. And admittedly, some of it is beyond me


Then that will be a problem. Are you certain you are the right person for the task then? I mean if you cannot articulate a better/best practice for some code, point out flaws, or just point to the sheer number of bugs can make a case for a more standardized approach? I mean for a bug fix (or feature addition) if that falls into the lap of a dev who didn't write the original code how much time is burned just figuring out what the hell is going on?

I get the need for structure and over all discipline, but being paralized and not able to articulate a point to upper management (or your fellow devs) makes this a nigh impossible task.

This post has been edited by modi123_1: 29 August 2013 - 11:35 AM

Was This Post Helpful? 2
  • +
  • -

#3 Momerath  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1012
  • View blog
  • Posts: 2,444
  • Joined: 04-October 09

Re: Talking about bad code

Posted 29 August 2013 - 01:23 PM

Sounds like your management got MBAs from any business school in America where one concept rules all: Does this activity increase shareholder value? Fixing bugs doesn't sell software, good code doesn't sell, refactoring, etc. all doesn't sell software. New features does. Until you can demonstrate that they can make more money by doing things the 'right' way, they will never change.
Was This Post Helpful? 0
  • +
  • -

#4 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Talking about bad code

Posted 30 August 2013 - 11:02 PM

Momerath is talking about the American health care system, right?
Was This Post Helpful? 0
  • +
  • -

#5 baavgai  Icon User is online

  • Dreaming Coder
  • member icon

Reputation: 5943
  • View blog
  • Posts: 12,871
  • Joined: 16-October 07

Re: Talking about bad code

Posted 31 August 2013 - 05:26 AM

View PostAhhmyface, on 29 August 2013 - 02:17 PM, said:

If it works, management is happy and we move on.


This. In a nut shell.

From a non programmer's perspective, this is the only metric. Most companies tend to think in the short term. Get to the next milestone, even if that means you've screwed yourself for some future milestone. This cycle, this quarter, this fiscal whatever, is the only thing that matters to some levels of management.

The benefits of doing it "right" are primarily long term benefits. Doing it right involves spending more time initially, in all aspects. A long design phase where nothing seems to happen can result in code produced more quickly after that phase, but can seem slower. Code that took longer to produce will take less time maintaining.

Indeed, the benefit of well designed code is abstract, in that it offers fewer problems; problems that never happen. A bug patch on clean code can take an hour, the same patch on crap could take weeks. But, from a management perspective, it takes what it takes. It's unclear that the prior decisions to get it out the door cost so much later.

What to do? Emphasize where the benefits of doing it right come from. Not in the development phase, but in testing and release. Fewer problems from the code in the wild. Quicker turn around on problems. Higher user satisfaction. If you can find in house examples, even better.

Code Complete by Steve McConnell, if you haven't read it, should give you some ammunition for your arguments.
Was This Post Helpful? 3
  • +
  • -

#6 Ahhmyface  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 2
  • Joined: 29-August 13

Re: Talking about bad code

Posted 31 August 2013 - 09:24 AM

View Postbaavgai, on 31 August 2013 - 05:26 AM, said:

View PostAhhmyface, on 29 August 2013 - 02:17 PM, said:

If it works, management is happy and we move on.


This. In a nut shell.

From a non programmer's perspective, this is the only metric. Most companies tend to think in the short term. Get to the next milestone, even if that means you've screwed yourself for some future milestone. This cycle, this quarter, this fiscal whatever, is the only thing that matters to some levels of management.

The benefits of doing it "right" are primarily long term benefits. Doing it right involves spending more time initially, in all aspects. A long design phase where nothing seems to happen can result in code produced more quickly after that phase, but can seem slower. Code that took longer to produce will take less time maintaining.

Indeed, the benefit of well designed code is abstract, in that it offers fewer problems; problems that never happen. A bug patch on clean code can take an hour, the same patch on crap could take weeks. But, from a management perspective, it takes what it takes. It's unclear that the prior decisions to get it out the door cost so much later.

What to do? Emphasize where the benefits of doing it right come from. Not in the development phase, but in testing and release. Fewer problems from the code in the wild. Quicker turn around on problems. Higher user satisfaction. If you can find in house examples, even better.

Code Complete by Steve McConnell, if you haven't read it, should give you some ammunition for your arguments.



I read the reviews of that book and it seems to be exactly what I need. If I can point to a reputable source and demonstrate we are violating good practice it will be much easier to convince people. It will also help me verbalize the things I already know so that they actually show up on managements radar. I ordered a copy from amazon. Thanks!
Was This Post Helpful? 0
  • +
  • -

#7 Martyr2  Icon User is online

  • Programming Theoretician
  • member icon

Reputation: 4443
  • View blog
  • Posts: 12,317
  • Joined: 18-April 07

Re: Talking about bad code

Posted 31 August 2013 - 09:36 AM

You are going to have to get use to companies that run software development like this. Many companies are run by business folk who really don't care about how software works. As pointed out they care about hitting milestones and selling. But I take the stand that if you can take some code, fix it and then relate it to the numbers of hours saved, and more importantly, revenue generated or cost savings you will quickly gain their attention. Even if the first time you do this it falls on deaf ears, keep doing it.

modi123_1 was spot on with the powerpoint idea. Even if you don't get a chance to present it, create the powerpoint, send it in an email along with an explanation of the fix and your revenue/savings figures they will soon get the hint.

The other day I had to do something similar to this and fixed an issue they had on their website with regard to vanity URLs. I devised a feature that allowed them to create catch all URLs that allowed them to push customers to particular sections of the site. I explained that this will generate new revenue because people who once tried to go to a dead or misdirected link is now going to find themselves right where we want them, on our products that we sell. They loved it.

Be sure after the fix to track its progress too. If a month later you can send them a note saying that the fix has landed them an extra $10k this month, they will certainly be more open to fixes. Especially if you fixed the problem in an hour. Because in their mind they spent 40-60 dollars for your hour but you netted them 10k on that. Excellent return on investment. ;)

This post has been edited by Martyr2: 31 August 2013 - 09:37 AM

Was This Post Helpful? 0
  • +
  • -

#8 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 3667
  • View blog
  • Posts: 11,500
  • Joined: 05-May 12

Re: Talking about bad code

Posted 31 August 2013 - 07:53 PM

Or conversely, you could show how a simple feature X or bug Y took Z number of hours no implement or fix because of how poor the current code is.

I had a recent project with a very tight deadline and was told to scrimp on the unit tests to be able to make the date. I made the date, but had the first "feature request" come in shortly afterwards which required some major rework. I told them that it was going to be about 20 lines of code to implement about 1 day worth of testing. When questioned on why it would take so long, I said that the 20 lines of code live at the core of the application. I could write the code, and just "toss it over the wall" to QA and hope that it doesn't come back, or I could spend the day manually testing the various scenarios. I made a point of mentioning that if I had take time to write the unit tests, I could have confidently have made the change, and verified that it works in less than an hour.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1