Developer angst!

lenovoguy

Hi there

I'm a software developer with 2.5 yrs industrial experience, and I work for a small company in Dublin. I work with a very large (900,000 LOC) mixed C++/MFC and C#/.NET codebase, with a lot of COM/.NET scaffolding gluing it together. The codebase is the sum of about 14 years work in total.

I had a bit of a meltdown in work last week as I had been working hard on a group of related features for the past three months. I stayed late a good few nights, not because I was asked, but because I wanted to get it done right, and this code finally went into QA last week. 30 bugs came back to me overall, and I felt quite embarrassed by this. I was ruminating over what QA must have thought of my work and how it would reflect poorly on me. However, as I thought about it more, I realised a lot of it is not my fault.

We have no real processes in place as regards development. I was never trained on our flagship product, so a lot of the time any bugs coming back to me are because some piece of code I added doesn't interoperate with functionality I never knew existed in the product! There are no code reviews, no coding guidelines (comments are few and far between), no daily builds, no testing methodologies for developers to check their work against. To top it off, there are only four other developers maintaining a nearly 1-million line codebase. All in all, it's a bit of a haphazard arrangement.

The other developers in here are working there a long time, and I fear they've become somewhat institutionalised as a result. I also worry, that if I stay where I am much longer, I'll end up in the same boat. The technologies I've mentioned, with the exception of .NET, are very old hat at this stage, and there doesn't seem to be much demand for them in the jobs market, so I don't want to end up with a set of skills nobody wants.

Looking at jobs now, the technologies in demand seem to be mostly for the web-based/web services end of things - Python, Ruby, JavaScript, Java/JSP, JSON, PHP, ASP,C#, XML etc etc. I can code in Java and C#, I've done a nominal amount of coding in PHP and and even tinier amounts in JSP and JavaScript, but nothing major. If I was to apply for jobs requiring these technologies, would it be easy to learn and brush up on them over a weekend?

Thanks

fergalr

lenovoguy wrote: »

Hi there

I'm a software developer with 2.5 yrs industrial experience, and I work for a small company in Dublin. I work with a very large (900,000 LOC) mixed C++/MFC and C#/.NET codebase, with a lot of COM/.NET scaffolding gluing it together. The codebase is the sum of about 14 years work in total.

I had a bit of a meltdown in work last week as I had been working hard on a group of related features for the past three months. I stayed late a good few nights, not because I was asked, but because I wanted to get it done right, and this code finally went into QA last week. 30 bugs came back to me overall, and I felt quite embarrassed by this.

That's not necessarily a bad thing.
Its very hard to know, without context, how big or bad those bugs were.
Maybe QA found them, they are easily fixed, and then you'll have a solid release?
Hard to say, but don't panic because of the number in and of itself.

lenovoguy wrote: »

I was ruminating over what QA must have thought of my work and how it would reflect poorly on me. However, as I thought about it more, I realised a lot of it is not my fault.

We have no real processes in place as regards development. I was never trained on our flagship product, so a lot of the time any bugs coming back to me are because some piece of code I added doesn't interoperate with functionality I never knew existed in the product! There are no code reviews, no coding guidelines (comments are few and far between), no daily builds, no testing methodologies for developers to check their work against. To top it off, there are only four other developers maintaining a nearly 1-million line codebase. All in all, it's a bit of a haphazard arrangement.

Scary.
Can you fix this?
Can you identify a prioritised list of processes that aren't followed, that should be, and talk to whoever has the authority to fix this?
Get buy in from them, and improve things?

It could be a really worthwhile, satisfying and educational project, to fix the broken processes and improve things - but you will need to get buy in from whoever is in a position of authority to allow the changes to happen.

That's the important point in such situations, I think - not just whether things are broken, but whether, if the brokenness is identified, there is a willingness to fix them.

lenovoguy wrote: »

The other developers in here are working there a long time, and I fear they've become somewhat institutionalised as a result. I also worry, that if I stay where I am much longer, I'll end up in the same boat. The technologies I've mentioned, with the exception of .NET, are very old hat at this stage, and there doesn't seem to be much demand for them in the jobs market, so I don't want to end up with a set of skills nobody wants.

Looking at jobs now, the technologies in demand seem to be mostly for the web-based/web services end of things - Python, Ruby, JavaScript, Java/JSP, JSON, PHP, ASP,C#, XML etc etc. I can code in Java and C#, I've done a nominal amount of coding in PHP and and even tinier amounts in JSP and JavaScript, but nothing major. If I was to apply for jobs requiring these technologies, would it be easy to learn and brush up on them over a weekend?

Basically, no, not over a weekend.
But programming in a .net language isn't too different to a something like python/ruby - you'd pick them up part time, over time, you probably wouldn't need to retrain or anything - but a weekend is too short.

lenovoguy wrote: »

Thanks

Just some .02, might not be helpful.

lenovoguy

fergalr wrote: »

That's not necessarily a bad thing.
Its very hard to know, without context, how big or bad those bugs were.
Maybe QA found them, they are easily fixed, and then you'll have a solid release?
Hard to say, but don't panic because of the number in and of itself.

Well that's a good point I suppose. A lot of them weren't bugs, but more "how should this work?" One of the weak points in the company has been requirements gathering - it's based around the "suck it and see" approach. Code a bit, see what the boss thinks, code a bit more, etc etc. It makes for frustrating work as the goalposts are always moving.

fergalr wrote: »

Can you identify a prioritised list of processes that aren't followed, that should be, and talk to whoever has the authority to fix this?
Get buy in from them, and improve things?

Well, as I said, we don't do code reviews, we don't have regular meetings to let each developer know what the others are working on, there is no feature-map to show how the different bits of the product interact with one another.
It's literally up to each developer to figure out what pieces of functionality his code will interoperate with, and remember to test it against them, which in such a broadly functional product, is very hard to do. There are no nightly builds, no documentation, sparse, unstandardised commenting, no coding style guides or conventions.

fergalr

lenovoguy wrote: »

Well that's a good point I suppose. A lot of them weren't bugs, but more "how should this work?" One of the weak points in the company has been requirements gathering - it's based around the "suck it and see" approach. Code a bit, see what the boss thinks, code a bit more, etc etc. It makes for frustrating work as the goalposts are always moving.



Well, as I said, we don't do code reviews, we don't have regular meetings to let each developer know what the others are working on, there is no feature-map to show how the different bits of the product interact with one another.
It's literally up to each developer to figure out what pieces of functionality his code will interoperate with, and remember to test it against them, which in such a broadly functional product, is very hard to do. There are no nightly builds, no documentation, sparse, unstandardised commenting, no coding style guides or conventions.

Right.
It sounds like there are a lot of best practice things, that would normally be done, and that you reckon should be done, but that aren't done.

Maybe there's a good reason for this - and maybe not.


Its good to realise that - but, can you sit down and think about this, and make a concrete list of what isn't conforming to best practice, and what should be fixed?

And then go find some supporting documentation - look at what is clearly marked as best practice in books, articles etc., that you guys don't do - and prepare a set of things that you are confident should and could be fixed, and how they could be fixed?


And then go and talk to whoever makes the decisions, and have a chat with them about what you think could be improved, and how?


Like, obviously don't e-mail everyone a rant, or hand your boss a report, or anything dramatic like that.

Wanting to make change in an organisation is something that requires a bit of soft skill.
Its got to be introduced gently, as a few suggestions, in a non-threatening, and no-big-deal kind of way.

But maybe just have a chat, that you are well prepared for, with whoever has the decision making authority, where you gently voice your well researched suggestions for things that could be improved, and see how they react.


Sometimes whoever is making the decisions just doesn't know what's going on, or know the right way things should be done, and will recognise a good, well-thought-out, suggestion, and take it on board.

Maybe they'd love to fix these things, but don't know how, or lack the time to think about it.


So, maybe try and 'manage up', and see if you can get some of these things fixed?
If you can identify concrete things, and bring them to the attention of who calls the shots, and get them fixed, it can be very rewarding.


But you need to prepare well - if someone says "OK, you're right, that is a problem, but what should we do now to fix it?" then make sure to have a well thought out, concrete, answer ready.
And go softly, don't step on egos.



Now, its of course possible, that for personal, or political reasons, that whoever you are talking to won't be receptive to those suggestions.

Maybe you'll learn that they have good reasons why some things you might suggest, aren't been done.


Or, sadly, maybe they'll be an ass, and react badly to gently put constructive and well thought out suggestions for change.

If its this latter case, where you are in a company you feel is badly run, and which isn't willing to entertain the idea of change, then maybe it is time to consider the overall state of the labour market, and moving company.


But I think its always worth trying to fix things, before looking to abandon ship - particularly if the organisation is small.


Now, these are just some suggestions to think about - obviously I don't know the lay of the land in your workplace, and what the dynamics are, so take anything I write with a grain of salt - but maybe its useful food for thought.