Designing well under deadlines that are too tight

Question

Hello SO;

I shall start with some background on myself. I am a junior programmer (almost entirely .Net, unsurprisingly) and have been in my first graduate job for just over a year; before that I took a physics degree and learned programming on the side, first Fortran and then C# off my own bat for a project.

After this relatively short amount of time I have encountered my first career-threatening moral crisis. I've learned a huge amount in my work and am starting to feel dissatisfaction with the way things are done. I've been almost completely on one project since starting; a desktop application that is due for release in under a month's time. The 'last' beta went out last week with several known issues. Release is already late by several months. Total staffing on the project is 5 actual people with about 3.5 full time equivalent - project manager, lead developer, myself and two mathematical modelling specialists whose time we have to fight tooth and nail for.

Every decision made hurts my sense of propriety because of a lack of good practice - a lack that even I as a mere yearling can identify. There is no unit testing whatsoever. Only one person in the entire company knows how to execute a build of the product. Design is ad-hoc and left entirely to the person writing the code. No seperation of concerns (model-view-controller architecture etc) is present. The modellers test their code in a production environment instead of in a test harness - so if we're working on the GUI with breaking changes, it holds up their work for half a day while we finish the infrastructure. This is particularly frustrating because I know the team have the skills; the lead developer is a trained software engineer - yet chooses not to use any of the practices he knows are recommended -and the project manager is entirely comfortable with coding as is evident from his code comments in 1980s era Fortran modules which are still left kicking around - yet doesn't get involved and doesn't inquire as to coding details.

The argument I get when I raise these concerns, which I am forced to agree with, is that there isn't time to do these things. Which brings me to the point, or probably points, of this question. The first is; how do I rectify this situation of unreasonable deadlines and distinterested team members given my extremely junior position? And secondly, the more interesting question; how do I go about proper design practice in a time frame that is known to be too short to do it properly; what do I miss out and what do I absolutely have to have to make it worthwhile?

edit:

I thought I should point out that not all of the company is like this. My line manager would and does wholeheartedly agree with most of the things I've said and is pushing hard for all the best practices to be adopted. The boss can only shoulder a limited share of the blame, as he's very hands-off and given his character, would probably be happy to accept our recommendations. The problem with that is that he doesn't have any day to day influence on how projects are run. He sets initial requirements, and if you tell him you can deliver them, that's your own damn fault when it slips. The root cause is lack of awareness on one side, and being risk-averse on the other. There is minimal clash of personalities or cultures and the team just needs someone to lead. I'm unlikely to be taken seriously in that position given my status.

Answer 1

My advise: Run. Be thankful for the experience, but run. Even if these people are nice, treat and pay you well (except if they pay obscene amounts of money, of course ;-). This sounds like some workplace that generates entries for The Daily WTF. My experience (10 years as a professional) has lead me to the insight that if you are in a company like this things will never improve. They might change, but not improve. That's due to the management which doesn't have the proper culture and doesn't value proper development methods. But methodologies are very important and way too often undervalued or simply not understood.

Your frustration will make you grumpy and miserable. Don't let that happen to you. No matter what management says, they maybe change a little bit here and there but most likely will fall back to old bad behaviour and not make the big changes in they way work is done that are necessary. There's nothing worse than a job that makes you think "Oh my god, I have to go there again" every morning, this can literally make you sick (in the physical sense).

Look for a better company. If your job at your current company is safe then you are in no hurry and can take your time to find a company that you like. Do ask about how they manage projects, if they use agile methods (read a bit about software project management so you know what they're talking about, e.g. at Wikipedia). Believe me, a good work environment also benefits the development of your skills.

At my last job change (also due to a company culture that sounds similar to yours, with no improvement in 5 years) I've seen something I haven't had before: test working. I was working at the new company for four days, without pay (it would have been against the law here in Germany as I was still employed full time by my now-former company). It was seen as a extended job interview (but of course followed a normal job interview). I really liked it because I got a chance to see the insides of the company, how they do things and also got to know my now-colleagues. This made my decision easy and with confident because I liked what I've seen and my now-bosses had a better chance at evaluating my skills. If this is offered to you, do it. If you have a bad feeling in a job interview (even you can't pinpoint why, trust your feelings in those cases) just say no. Remember, you are trying to make a decision for your next few years so be picky !

BTW, if things are organized correctly then there is time for testing, there is time for designing, there even is time for writing prototypes. And at the same time run a profitable company. It's a question of culture. I am experiencing exactly this right now and am very grateful.

Answer 2

Read this book.

And sneak a copy onto the manager's desk.

Answer 3

RUN FOR YOUR LIFE, GET OUT OF THE BUILDING ...

yeah, you should get away from that company. start looking for another job. You do not want to waste your time fighting for reforms in that company, it's not your dad's. I used to work for a company like that. they used to give me code supposed to be written in a period of 2 weeks and ask me to do it in days.

guess what i did ?

I stopped showing up. I RAN .........

Answer 4

Hello Tom
I just want to throw in my 2 (euro)cents too.

The good side of this is that you will like your next work better. :) But there will be problems in every company your will work in and it will be thing that you can't do anything about. I know it is frustrating to see things that can be done for improving the situation but unable to do anything about it.

A little tale
I worked in a company where one of the codebases were in a mess. It was written in C++ but without classes. They handled classes much as containers for functions. No-one was responsible for the entire system. I told them that it would be much faster with a rewrite, having classes to model the business logic, divide the code in responsibilities, you know. As it was a large company a feasibility study had to be written, I wrote it, added a skeleton class diagram, rough partition of the system. To my surprise a generous amount of time was set aside for making the refactoring of the system.

The manager in my department didn't set me or anyone with system engineering experience. Instead they put the one that have written a lot of that miserable code to refactor it. They wanted to restore the work group harmony that have been upset by suggesting that the code was badly handled.

Five years later that department didn't exist anymore and the products had been moved to another department. I don't think that it was only this that was the reason, it was a lot of other inefficiencies too.

People
Persistent problems in design almost always boils down to peoples problem. The manager is responsible for the performance of the people that works for him. The lead designer is responsible for the design. The project manager is responsble for deadlines. The management is responsible for the profitability. You are responsible for delivering the code you are paid to write.

The lead designer know or should know how to design the system. There is a wast amount of information out there how to write good, reliable code. Books and books have been written about how to lead a project. The management should have reacted the first time a project missed the deadline.

The company have a culture of passivity in front of the problems. Culture take a long time to change in a company.

Advice Besides to leave the company, which I wholeheartedly agree with, I will try to give some advice on how to make a work to be proud of:

• Try to follow your own suggestions, such as unit test, as a matter of your personal best practicies. I think you can find some time to spend on writing some extra pages of psuedocode algoritms, diagrams to clarifying the behavour of the code and the unit tests.

• When you is find yourself sitting and making random tweaks, take a step back and make a diagram or a psuedocode or anything for clarifying the situation for yourself. If you find yourself not knowing what to do it is not for the problem being to hard, it is that you haven't clarified the problem enough.

• Write down the problems that you see in the company and try to analyse them. This is entirely for your own sake. To feel that you have a handle on the situation. Maybe will come in handy later.

• I have got insights from the book The Toyota Way by Jeffrey Liker. While it is about manufacturing, it give example of a very good mindset and a very good culture.

Good luck, wishes
Gorgen

Answer 5

I don't think the only good choice is to leave. The good news is that you recognize the problems and you actually already have an idea of what the answers are. If you accept the challenge this could be your chance to really shine. It could be your chance to try to improve a development process in a meaningful way.

Don't get bogged down with trying to solve all the problems at once. Pick something small that you think will help improve your teams performance and start by implementing the change to your own process. If it works well share it with the rest of the team and hopefully they will see your wisdom or at least be willing to try it out. One small success can get the ball rolling and can get the attention of higher ups that have the power to give you more resources to continue improving.