What to do when your company thinks in hours rather than months?

Question

I have about seven years of commercial experience. I work for a company which can only be described as a post start-up. It's been going eight years but has a staff size less than ten.

We have some cool projects with some really big companies in the UK and I do actually enjoy about 20% of the work. But ultimately I'm a maintenance programmer and I hate it.

We seem to sell a service but we try to sell it as a product. Yet it's a product that we end up with customising for every client. It seems like we do a lot of work without making that much money.

I can't help but think that the company's business model is somehow broken. Am I just being arrogant or am I right?

The quality of our code base is fairly poor; it's a fairly big gloopy ball of mud. This isn't because we want to do a shit job, it's just that we simply can't afford to do any better. We think in days of development rather than weeks or months. With such short time spans for projects, how can you do any better?

I'm sick of working on a giant snowball of mud. The problem I have is that I believe that nearly every company in the north-west of the UK suffers these problems. Interviews I've been on seem to confirm my suspicion.

Am I just being an arse or do I have a genuine complaint? Is it worth looking to move and , if so, what would your next move be?

Answer 1

This is not a direct answer to your question, but it still is an answer. Sort of.

There are two types of places you can work at:

• It's the place where you know you will leave due to a pension agreement
• Everywhere else

The first place is the one you want, the others... they're temporary, who cares what they do or how they do it? Do it their way and just look beyond the horizon. Find a new place to work that is better.

I realize this answer can sound kinda flippant. "Yeah dude, just move on, find somewhere better to work!".

But the truth is, if you don't agree with the choices your current company is making then you have only two choices:

1. Get them to change
2. Move on

Answer 2

If you hate what you're doing, either change the model or move on. I would be thinking about how to incrementally improve the code base. Most importantly, does upper management want to get (back) to a software products model?

But it's easy to say move on - the reality is that we have bills to pay and mouths to feed and a sucky programming job is still better pay than looking for work; move on when you have a concrete better prospect.

Often times a software company ends up in a services model out of desparation - because services are specific, they meet an immediate customer need and the ROI is more obvious, so they're easier to sell, esp. in lean times. So it's easy short term money and it keeps the doors open and the lights on. But there's no resell value, so there's no additional revenue from the work - software makes the most money when it's resold in volume because the costs are mostly the same whether you sell 1 or 1,000,000; burning more CDs/DVDs is effectively free. You need to sell that idea to management and get their support if anything is to change.

Our company has become trapped in a services model for a number of years due to the poor economy, and is struggling hard to return to our roots as a product organization - I am actively involved in our pursuing that goal, but in the meantime, I just deal.

That said, I enjoy the vast majority of what I do, and most of it's good stuff that is often very challenging.

Answer 3

8 Years and you are ~10 people? That's not a business model, that's surviving. I suggest moving on or becoming seriously vocal and active to get to the next level. If you don't have a business model that is built for serious growth, you will just go on surviving until something comes along and whipes you out.

Answer 4

This question and current answers seem remarkably similar to this one:

http://stackoverflow.com/questions/12745/how-do-you-handle-poor-quality-code-from-team-members

Answer 5

Its normal. Eventually you (ie management) will realise that maintaining all those customised products is costing too much and you'll embark on a rationalisation programme.

If you wrote shrinkwrap software you'd be adding new features to it until the bugcount got so high the management noticed and then you'd embark on a new-feature-freeze maintenance release.

I trust you know of the real Big Ball of Mud design pattern. Perhaps reading it will suggest some solutions to your problem, if not send an email round suggesting some consolidation of common customisations that could be better done in a single block of code that is switched on or off using configuration parameters. Once that gets some traction, it'll be implemented more and more by your peers for other areas.

Moving won't necessarily help you (especially at the current time), a heartfelt discussion with your colleagues and manager would.

Answer 6

My first job was for a small Web development company. It was a strange setup; all developers worked individually. Each week or so a contract would land on your desk, and it was my job to construct a PHP Web site that conformed to that specification. Schedules were tight, the sites were usually similar enough just to bore me to tears, and trying to introduce new methodologies like unit testing or even standards-compliant HTML was met with resistance, because we didn't really have the time. When completing the project determined whether or not your paycheck bounced, you certainly had an incentive to get the job done on time. I learned a lot, but after a year I was sick and tired of the projects and was burned out. All software jobs have some repetition and tedious drivel, but this was by and large the same skill set day in and day out.

I left the company on good terms and moved into Windows development. The sea change was incredibly important for me to become a well-rounded programmer. Sure, I still have days where I look at my current job's code base and think "My God, what have I created?" Other days, I look at the same code base and think "This is awesome, I can't believe this all works, is used by thousands of people, and that I wrote it." And as long as I still have those optimistic days, and that those days outnumber the pessimistic ones, then I'll stick around.

My bad advice? Leave when you're bored, when you think you've exhausted what you can extract from the company. You can voice your dissatisfaction with your manager, but don't try to change the company outright, even if you think you're right. I've thought similar things at previous companies, but we do not have business degrees or marketing degrees; as much as we can poke and tease such professionals, we're software developers, we're good at making and designing software, and anything else we claim to be good at (marketing, resource allocation) is probably just hubris. They've found a model that works for them and the company--that doesn't necessarily require that it works for you.

Answer 7

There is nothing you can do. Was exactly in same situation. You can not change your customers and company will not change before customers will demand it.

Well in fact may be you cannot do it quickly.

First of all try to be the best among your peers. Do not offend anybody and not not insist that they are jerks. Just do your best. Never complain o interviews about your current employer. It hurts feelings bitter sentiments that is all. Be professional. After all it is what professionals are paid for.

Btw maintenance is not bad. It is difficult and normally require slightly better qualification then other programming tasks. That different.

Answer 8

Man, I think we work for exactly the same company. I've been giving this question much thought myself as of late. My conclusion, and this may seem a little cynical, is that if a company is still in that mode of operation after about 5 years, there probably isn't anything you can actually do to change it, unless you somehow manage to score a seat on the board of directors.

Answer 9

You can build software with short time frames, but it only works if you commit to quality software development. With small teams and short timeframes, quality becomes even more important because you don't have time to find bugs and fix them. You have to use methods that reduce the number of bugs you produce in the first place. I can't guarantee that it will solve your problems -- mainly because they are more cultural than technical -- but changing to a test-first development process and committing to quality first, i.e., no code goes out with known bugs and all code is unit and acceptance test, will certainly help in the long run.

Answer 10

Uuuhhh maintenance coder... That's when you spend hours debugging some kilometric mud method and just want to kill someone.

var names are like

temp, temp1, temp2, temp3, tmp, tempe, ttemp.

Or you have a lot of comma separeted data in strings.

:(

The worst comes when you realize some of those terrible method were written by you!

Well I thing we all shall start as maintenance but at the beginning of our careers so we can learn the bad stuff first, not after seven years.

Something very similar happened to me.

You have to hang on for a while, talk to your manager and tell them you don't like what you're doing. ( if you're in the management team don't talk with your partners, or they'll leave before you!! )

But definitely, no matter how much we love a company, or a project ( because we see it grown since it was a couple of modules long , we coded some main core parts of the system, right? ) You have to leave.

Sometimes after you talk with your boss, you're promoted to something like whatever manager and then you have to supervise others, thats a relief for a while, although since you mentioned you're only 10, I don't thing this is an option.

Start looking for something new, and leave. With no regrets, you did the best for the product. You leave hours and days in the keyboard. You are not in debt.

You probably find after some years to your old mates an will laugh. Chances are you open a new company with them : )

Answer 11

I work for a company with very similar problems. The window of opportunity for us is usually just a couple of weeks, and that involves a huge push to get code written in time. The result is the same as for you: messy code, lots of programmers working in "maintenance mode", and difficulty bringing new people up to speed.

For us, we have no better option, for now. However, we're in the process of regrouping, and building a framework and a huge library of well-written templates that we can use to make things more maintainable while still giving us the ability to go to market with new stuff quickly.

Ultimately, the answer is: keep learning. You've made some mistakes, so you should learn from them. As you learn, try to think of ways to prevent those mistakes in the future. Given the way your company operates, try to anticipate issues before they come up, and think of ways to solve those problems in advance.

Answer 12

One advantage of working for such a small company is that you have the power to actually change things. I've worked in similar environments, and I've been able to push development in the right direction. Places where there was no source control, I instituted the use of source control. I took it upon myself to re-architect parts of the application that were simply unworkable. Things never got to a perfect state, but they were much better than when I started. Don't expect things to change overnight, but realize that likely things can change for the better over a course of a few years. You have to be in it for the long haul, otherwise your effort will be all for naught. The nice part about that, is that if you are the leader for change, and get the company on the right track, in such a small company, you will be noticed, and will probably be rewarded, if not financially, at least rewarded by the respect of your colleagues. If you want the company to stop thinking in terms of days and years, you, yourself have to stop thinking in those terms.