Software

Ask something
Discussion Locked

Sloppy Software Development

0 helpful
42 replies

by codebubba

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I'm curious. Does anyone else out there among us developers run into this all the time?

I'm working on a "team" of 15 to 20 developers. Some are older, many are newer. The application has existed for quite awhile now.

Over the years I have managed to get good control of the component (which is pretty low-level). I have developed a routine of development that involves not only compiling the code before checking it in but of unit testing it for functionality. When I check in code it has an excellent shot of being right the first time - and it usually is. I'd say I get, maybe, 2% of my issues sent back due to a test that showed something I might have forgotten.

However, it's obvious that I'm in the minority when it comes to really being careful about what I check in. I would say about 90% of the time when I get the latest version of the code I find myself fixing problems (often critical) that occur in the application "on the way" to an issue I'm trying to work with. Many many times the problem is because someone just changed the code, stored procedure or database and didn't consider anything about what it could affect. I'd say I spend 30 to 40 percent of my development time sorting out and fixing OTHER PEOPLE's problems before I can get back to working on my areas because of this slop.

Anyone else running into this? What ever happened to quality-mindedness when developing software? Maybe the idea is just a fantasy of mine. Is it expecting too much for developers to TEST the stuff they work on before checking it in for others to crash on? ARRGGG!!!

Sorry for the rant ... some days I think I should look for a job somewhere else where they do it the way I'd like - but in the 30 years I've been doing this I haven't found one yet!

-CB

42 replies

by dr dij

when they check incode.
there should be unit (module) tests that run.
a minimum of daily build, or when they check it in.
/ end of day.
and it has their name as author of last changes so parcel it back tothem to get working

read a great book on this; a few months ago, may have been

Software Testing Techniques: Finding the Defects that Matter
by Scott Loveland et al.

isb 1584503467

Be glad you're not on an extreme programming team where no one is responsible for the code and anyone can refactor it.

hilarious book on this:
extreme programming refactored

by tony hopkinson

Working on the legacy stuff which is pretty bad, we occasionally get an unintended consequence.

Got to say you aren't doing yourself any favours by just fixing them, you've got to go back to the author and find out what the thinking was. Not confrontational you understand, after all may be you missed something. :D

Sounds like an ownership problem to me. If I make a change to something and I miss a logic path or break something in another application, it comes back to me and I get to learn how not to make that particular mistake again.

Setting things up the way you like, means you have to climb up the food chain and you end up doing more setting up and policing than you do doing. It does have it's rewards though.

by codebubba

Yeah, Tony ... think you're right about that. I do run into the issue of "ownership" (or lack of same) quite a bit in the shop.

The main problem, I think, is at the management level. We have some good developers but the leadership doesn't have a clue about how to properly execute a development plan. Even though we're owned by a large company, we're still operating like a small one - development driven by sales. As long as we're sales-driven then we're going to continue to have problems with "fantasy deadlines" (as one of the developers put it) and no real planning or specification. I think this might be the "root cause" problem here. These developers, particularly the newer ones, are being handed vague specifications and pie-in-the-sky deadlines. The resulting pressure turns our shop into a mud-throwing act rather than a truly coordinated software development group.

-CB

by tony hopkinson

legacy code
no time for refactoring
fixes are 'too risky'.
Turnover in personnel means no standards applied or policed.
Every thing takes much longer than it should.
No one has any confidence that a change is localised.
QA do massive regression tests.
Senior developers keep saying we could do with rewriting this.

Getting warm here ?

by wayne m.

I would recommend the best way of dealing with the situation is to not spending time trying to correcto problems caused by others. It will merely get you upset and never really resolve any of the underlying issues.

The basic idea is to work within your own sphere of influence. Until one is in a position of authority, one cannot direct others to work differently. The best one can hope to do is to influence peers when they ask for help.

Concentrate on solving the problems you are tasked with. Ignore sideline issues that may have been caused by others and allow your management to address that problem.

by codebubba

I agree completely Wayne. That's pretty much what I've been doing for all these years but sometimes ya just get annoyed at these kinds of things. I have to keep reminding myself of this once-in-awhile.

If the powers that be want to screw things up, that's OK - it just won't be my piece tha causes it, if I can help it.

-CB :)

by onbliss

...good programmers. And they are bound to see that nobody is able to stem the rot or manage the issues. It can affect the quality of work even from the normally good programmers.

by codebubba

Yes ... and it does. We've had a pretty high turnover in this department because of this. We get new guys in here and after a few weeks we start hearing "WTF" when they're tasked to produce something with little or no specifications (other than the "architect" saying "do it") and a "fantasy deadline" (a term coined by one of the new developers) imposed by the department manager.

After a quick mental review it seems to me that the average "life" of a developer in this shop (except for a few of us older "legacy" guys) is between 6 to 9 months.

-CB

by why me worry?

as what is described here is indicative of their "high quality" workmanship that needs to be scrapped and redone by someone with a clue. I see this everyday as a consultant who has to deal with shoddy code coming out of the development department (over 90% of them are Indians on H1-B work visas) firm I consult for. Mind you, I am not a programmer, but I provide servers to developers who install their custom in-house software on the server, only to have them corrupt the operating system and require a complete reinstall of the system once they are done messing around, which happens almost 99% of the times! With that stated, I am supposed to be content with this nonsense? I don't think so!

by tony hopkinson

But no, it's standard sales directed bean counter thinking.
Course so is selling off your coding to an external party without retaining / recruiting the skills to manage such a thing.

I talked to the sales oriented MD at our place, he said he found the fact that our department had very high rates of staff retention worrying.
High turnover works in sales apparently, doesn't work in an engineering or support disciplines at all though.

by codebubba

Actually, now that you mention it, yes - that is a fairly significant reason for problems in our code. A couple of years ago our management thought it would be cheaper to hire an offshore outfit (India, of course) to rewrite a CRITICAL section of our application for the web.

To make a long story short - after about 18 months we discovered we would have to rewrite about 80-90% of it because the code was just pure CRAP. I would not hire one of those guys (at this particular outfit) to mow my lawn let alone write code. We spent the next year fixing bugs in that junk.

-CB

by onbliss

Code actually not in the source safe :-)

But CodeBubba mentions about sourcesafe in the very first post. Apart from the things that you mentioned, I have seen companies working "smoothly" with some parts of the source code just sitting on the developer's machines. It is scary to think that source code has not been properly inventoried.

by codebubba

onbliss ... I couldn't reply to your other post, it was getting too deep.

The firm I was referring to that we used to do our offshore development was, I believe, called eSoft. The code they wrote was dismal.

-CB

by onbliss

It calls for a good leadership - both technical and non-technical to have a good software development in place. And this translates to time and money.

One way to improve is document and demonstrate the time and money the company is loosing - in short and long terms.

by tony hopkinson

place from day one, Grafting quality onto an existing development, especially if it's out in customer land, is an extremely expensive option.
Top 'boys' admitting they screwed up, not popular at all.
The product is generating revenue, it does work. It's the cost of keeping it working when adding new features and proving it's not broken, where the real costs will be seen.

At that point aggressive neglect comes into play and just makes things worse. Bean counters are cash flow types, deferring costs always makes sense, after all you may not ever end up paying them.

by onbliss

...if the managers' turnover is higher than the developers :-) Points to the fact that they could not change the system.

by codebubba

onbliss ... you asked the name of the firm that we outsourced with in India. They were called eSoft if memory serves. I tried to post this yesterday but it didn't get in for some reason.

-CB

by onbliss

Yeah, I saw your post yesterday. I went to esoft.com and they appear to be providing security products & solutions; nothing about software development for others.

by phil.helms

My only first hand experience with an Indian software firm has been different from the one previously mentioned here. I can't vouch for the other developers they sent us, but the one whose work I know was a shining star. Broad technical knowledge, well executed development work, helpful, modest, much relied on. When he left us after 18 months, it was a real loss.
His company: TCS.

by codebubba

Yup. I've seen 4 of 'em come and go since I've been here - and a dozen or more developers. (I've been here 8 years). It's beginning to look like time for another "change of command" to take place. The track-record of this particular administration is not much better than the ones in the past.

-CB

by onbliss

I was in a project where even the best mind and intention could not have achieved much, because the development team had managed to squeeze them into a position where the business model never gave the team any room to innovate and refactor (design & code).

Some blame needs to be assigned to the developers too. They never put their foot down. They were not asking for salary increases they were asking for a proper way to develop software. And everybody's hands seem to be tied down.

by tony hopkinson

That there are a lot of very simple things developers can do to ease ongoing maintenance from the get go. Unfortunately these are a chapter 13 filler on most programming courses and barely taught at all.
So we pick them up from the 'I'm not doing that again strategy'. Still at least it means us experienced types have easy ways of adding value. :D

Really simple things like when doing shake and bake call a routine from the event handler instead of putting five pages of code inside it...
The MVC pattern, you'd think it was rocket science or something!

by neon samurai

That's one place I see it anyhow.

Developers rushing to meet a deadline will code "good enough" quality work. Get the software out the door and producing profits (or freeing your developers for the next task in a long list).

Few development groups code on the basis of "release when it's ready". This is probably more due to management focuses on deadlines rather than project completion.

What a world it would be if all developers could choose there projects, deliver when the code is ready and gain from other's code and testing... wait.. that world exists already.

by tony hopkinson

on that front, though I'm not sure it's happening for the right technical reasons.

I see it as a pendulum swing. We started out Waterfall. Everything documented, out of date, over time and over budget. Swung over to QAD (RAD in the real world) Nothing documented, nver finished, Budget & Deadline???. Now we are swinging more towards fit for purpose and effective.

Unfortunately there's a serious past investment in a lot of juvenile or just plain crap designs, and that's very hard for the business types to just write off, even though doing it properly is the best long run option.

by wayne m.

I would probably try to see if the management cares about either the turn over or the system quality. Try to track down one of the more senior managers for coffee or lunch. Try to express some of your recommendations and avoid having it sound like a gripe session. If the management recognizes the problem, giving them a plan of action may help.

If the management doesn't care, then look at the company stability and your own frustration level. If the company is having financial problems, get out. If the company is on the verge of being acquired, stay (if you have many years of service, you will get either a retention bonus or a good severence package). If the company is just trudging along, then decide what are your key issues (commute time, type of work, salary, etc.) and start looking. Don't settle, but go after anything that meets your list of key issues.

6 - 9 month turnover is usually a very bad sign. I hope your management cares enough to want to resolve it, but you may just have to look out for yourself.

by onbliss

..I remember Martin saying something about Managers and refactoring :-) Concerned developers do refactoring, sometimes without telling anybody. The trouble comes when they do not test it properly (regressive) and the application breaks :-)

by tony hopkinson

has strayed into re-engineering.

I view any need to regression test an indicator of a poorly configured and or designed code base. After all it means you don't know the impact of the change before you make it. Unfortunately all too true in a bad or neglected design.

I used to be a bugger for just making a simple little improvement on the sly, I learnt that lesson though, when it went severely pear shaped on me.

by codebubba

I don't think so. It was a couple of years ago, though ... I wouldn't be surprised if they don't exist any more. eSoft is a pretty generic name, too. Considering some of the management decisions that were made during that time I wouldn't count on it as a legitimate outfit anyway. Their code sucked, that's for sure.

-CB :)

by the family jules

i've known a few developers that would rather write code than re-use existing. then they use their own naming conventions/nomenclature rather than conform to existing project standards.

Anyone ever read "How to write unmaintainable code"? :-)

by tony hopkinson

either is the past, the code is already unmaintainable, or now the code is about to be unmaintainable.

One thing to be careful of, standards should be set by the development team, not some muppet who starts saying you must use hungarian notation.
And you end up with

tblTable.fldField[strFieldName] = mnyNetProfitinDollars;

by codebubba

>> And you end up with

tblTable.fldField[strFieldName] = mnyNetProfitinDollars; <<

Reminds me of some of the silly naming conventions used in our database. It's bad enough to come up with these long names but to use them both in the table name AND the column names is nuts. For example - if I want to reference the auto-number ID column of the category table?

SELECT DOLLARS_AND_CENTS_ACCUMULATION_TABLE_ID from DOLLARS_AND_CENTS_ACCUMULATION_TABLE ....

I'd have just named the column (which is the primary key) simply ID. Foreign Key references would be simply DOLLARS_AND_CENTS_ACCUMULATION_TABLE.ID instead of DOLLARS_AND_CENTS_ACCUMULATION_TABLE.DOLLARS_AND_CENTS_ACCUMULATION_TABLE_ID

I kid you not ... someone in this shop actually named table columns using the name of the table as prefix to the column names!

If we're going to do that, then instead of using a directory structure on our disks, let's just include the entire directory path in the names of all the files even under the directory.

C:\PROGRAM FILES\Microsoft Office\whatever\WinWORD.EXE now becomes

C:\PROGRAM FILES\Microsoft\Office\whatever\Program_Files_Microsoft_Office_whatever_WinWORD.EXE.

Sheesh...

-CB

by tony hopkinson

That was a tactic, our legacy database still features it from dos days.
When you do a join you don't have to use full qualified names and you can tell where the data 'comes from'.

In my opinion not enough to sell me on the idea, but it must have been a school of thinking at some point, because I've seen it several times.

by cvicd9

I design medical software for my office and try to sell some and what you say is 100% I am yet to encounter a programmer that listen, take hints and try to resolve problems for the user and do a good jot the first time. Is my dream to have a partner like you. Lucky your employer. Keep it up

Carlos
SAMS

by tony hopkinson

Not even the best of us manage that, job usually changes during the life time of the development.

Most of this is environment. If a business wants a quality code base, it has to invest in it. The return is very good, but there is that initial outlay and it will delay time to market for version 1.

One of the investments is in an experienced developer, get someone fresh out of college and they will have to practice on you.

A good way round that is to employ someone who has the tee shirt on contract to bring a novice on and provide the software with a sensible foundation and framework. Can you afford a tried and trusted professional and a junior for phase one though. That's a business constraint not a technical one.

by jean-simon.s.larochelle

...and if you can pickup some good advice along the way then it's even better. One of the most disturbing part in this is to see people not wanting to invest any extra in learning a new technology. The other day I was building FindBug project files as a service to other people in the project (most of them with less seniority than me). To test my configuration I ran some of the new modules into FinBug. I was surprise to see basic mistakes pop-up in code from junior and more experience programmers. Things like using constructors on Boolean instead of calling the factory methods and other such basic stuff. This kind of correct usage stuff is all in Joshua Block "Effective Java Programming" and I think everyone writing Java code should have read this or the equivalent. Some of them will argue that the company should invest in formation but in this case it's like asking an hospital to show doctors how to use a stethoscope.
So I e-mailed everyone to explain some of the basic of using primitive wrappers (in an attempt to be friendly I call this kind of e-mail "Java tip of the week" but I think I should change the name to "Kick in the ass of the week")
Don't get me wrong I also make mistake but man... Really discouraging...
JS

by codebubba

... usually creates a stink (if you know what I mean) ;-)

I was really frustrated when I wrote that original post though. Usually after awhile I calm down and realize that if I'm not on the management level there's little (to nothing) I can do to influence that. I don't want to be management.

So ... I'll just let the others screw it up, sit back here in my corner and produce the cleanest stuff in the shop. If they want to combine it with something that blows up then at least it won't be my component that causes it. No point in getting frustrated over stuff you can't control.

-CB :)

by jslarochelle

...medium to long term. People will see your code and learn by looking at it and also possibly get motivated by your work.
But it does feel good to talk about it (for me at least).
JS
:-)

by tony hopkinson

are management.
Either the firm is chosen simply on the basis of cost and or the required processes from in-house to external are not in place.

Seen it happen several times, 'you' did have guys with a lot of business knowledge, and then you go to none.

That means a lot of dotting is and crossing t's, clear documented milestones.... All those things you'd have done if you were having a turnkey system produced by an external vendor.

This discussion is closed to new replies.