The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Balancing reliable and maintainable code with completing the tasks on time.
Tzyr
Registered User regular
Registered User regular
Need the opinions of other programmers/software engineers. Even managers in the respected field would be appreciated too for it would give a different perspective.
I am having problems at work and I want to know how others balance design vs completion, and stability /reliability vs simply getting a task finished. When you are given a task/problem, how do you go about attacking it? Like, if you are given (a soft) 2 weeks to complete a task, how would you break up that time?
You can respond to the above question for ideas what others do is something I am looking for. I have included why I am struggling below, but its long.
I am also curious if what my coworkers do is "normal" or acceptable, and that I just have to learn to either get much faster or to conform to what I think, is terrible practice (I'll explain more in a bit).
First a background. I am a Test Engineer at my company with my responsibilities are to automate and write test scripts for automation, and have reports being generated of the results. I also create tools to help out both development and QA.
I have been doing this for about a year and half now, with a year in QA before that. Granted, I've moved from different teams/departments a couple times so every time my responsibilities are completely different.
The problem: whenever I am given a task, it usually takes me twice as long as what the estimated time to complete the task was given. Now, I'm horrible with times so they are not my estimations; they are estimations of what senior software engineers or the technical director would give.
The biggest problem I have is that I am able to complete the task in the given time if I just throw it together as fast as possible, without too much testing or any concerns about maintainability or reuse-ability. It just seems the common practice of where I work is get it working quickly, and if there is a problem, fix it; else, you are golden.
Maybe it is the perfectionist in me, or my naiveness of a junior level programmer...but is this really how things are done?
Please understand that no, this is not how the senior SEs or the TD work, at least from what I can tell; but other the junior programmers (who have more experience than me) who I work with. The problem is, since they are my co-workers doing similar jobs as me, they complete tasks quickly and thus make management happy; putting that much more stress on me since they would finish a 2 week job in a week while I might push 4.
It is making work very hard and stressful for me since I will stay late nearly every night working to 9-10 maybe even 11 pm (without getting paid for the OT mind you); and I still cannot get it complete in the estimated time.
The problem with their solution or work? Yeah, theirs breaks, a lot. It might appear to work, enough that they can claim it is finished, but if you run it a bunch of times it will break and then they (or even myself many times) will have to fix it. But that's how they see it. Get it done as quickly as possible, if it works and no one complains, you are good to go. Else, fix it and wait for it to break again. Now of course, not everything of theirs breaks, but I think the stuff that works is more meh, that's good enough.
Now, I have talked to the senior SEs and TD to get their opinions, to which they usually respond by saying I am over thinking/designing things; but with everyone being busy with their tasks, it always seems that I am (or may be) bothering people. I do not want to be a burden on people, which is why I stay late (or work on the weekends), or come to you guys for advice.
Why does it take me so long to finish a task? I over think things...everything. Even mediocre tasks. But I always feel that though a lot of what we do are not computational heavy tasks, just because it works does not mean we should not care if what we are doing is very inefficient.
For example of what I mean by shitty code or poor practices. A lot of the work that my co-workers do is simply everything is static/singletons, with god classes that handle everything that you inherit from, and a lot of copied and paste code everywhere. Nothing is commented and because everything is mashed together, there is almost no reuse-ability (unless you just copy and paste and edit parts). This ends up being why there is so much repetition of work being done and why a lot of things break (or not work as expected).
Me on the other hand, I would write helper libs that are generic enough that could be used by anyone who is doing a similar task. The problem though is by doing something more generic it takes a bit longer.
I also test/debug my scripts and fix any issues before I feel comfortable releasing. My co-workers? They will release their work and say they have completed it and let the test run. If the next day the e-mail reports anything wrong, they will fix it; else, they will move onto their next task.
I...just cannot bring myself to do that. But in the end, I end up submitting things well past the given deadline.
Help, please? I do not feel very secure at work and I would hate for my stubbornness to be my downfall. (Understand though that I've not had a talking to from my managers regarding my work, so my lack of feeling secure is more me thinking why would they want to keep me when other people can finish the work much quicker?)
TLDR: Having problems at work worrying too much about design and stability. Need opinions on how one balances writing well written/reliable code with time/deadlines. And maybe examples of how one might approach a project.
I am having problems at work and I want to know how others balance design vs completion, and stability /reliability vs simply getting a task finished. When you are given a task/problem, how do you go about attacking it? Like, if you are given (a soft) 2 weeks to complete a task, how would you break up that time?
You can respond to the above question for ideas what others do is something I am looking for. I have included why I am struggling below, but its long.
I am also curious if what my coworkers do is "normal" or acceptable, and that I just have to learn to either get much faster or to conform to what I think, is terrible practice (I'll explain more in a bit).
First a background. I am a Test Engineer at my company with my responsibilities are to automate and write test scripts for automation, and have reports being generated of the results. I also create tools to help out both development and QA.
I have been doing this for about a year and half now, with a year in QA before that. Granted, I've moved from different teams/departments a couple times so every time my responsibilities are completely different.
The problem: whenever I am given a task, it usually takes me twice as long as what the estimated time to complete the task was given. Now, I'm horrible with times so they are not my estimations; they are estimations of what senior software engineers or the technical director would give.
The biggest problem I have is that I am able to complete the task in the given time if I just throw it together as fast as possible, without too much testing or any concerns about maintainability or reuse-ability. It just seems the common practice of where I work is get it working quickly, and if there is a problem, fix it; else, you are golden.
Maybe it is the perfectionist in me, or my naiveness of a junior level programmer...but is this really how things are done?
Please understand that no, this is not how the senior SEs or the TD work, at least from what I can tell; but other the junior programmers (who have more experience than me) who I work with. The problem is, since they are my co-workers doing similar jobs as me, they complete tasks quickly and thus make management happy; putting that much more stress on me since they would finish a 2 week job in a week while I might push 4.
It is making work very hard and stressful for me since I will stay late nearly every night working to 9-10 maybe even 11 pm (without getting paid for the OT mind you); and I still cannot get it complete in the estimated time.
The problem with their solution or work? Yeah, theirs breaks, a lot. It might appear to work, enough that they can claim it is finished, but if you run it a bunch of times it will break and then they (or even myself many times) will have to fix it. But that's how they see it. Get it done as quickly as possible, if it works and no one complains, you are good to go. Else, fix it and wait for it to break again. Now of course, not everything of theirs breaks, but I think the stuff that works is more meh, that's good enough.
Now, I have talked to the senior SEs and TD to get their opinions, to which they usually respond by saying I am over thinking/designing things; but with everyone being busy with their tasks, it always seems that I am (or may be) bothering people. I do not want to be a burden on people, which is why I stay late (or work on the weekends), or come to you guys for advice.
Why does it take me so long to finish a task? I over think things...everything. Even mediocre tasks. But I always feel that though a lot of what we do are not computational heavy tasks, just because it works does not mean we should not care if what we are doing is very inefficient.
For example of what I mean by shitty code or poor practices. A lot of the work that my co-workers do is simply everything is static/singletons, with god classes that handle everything that you inherit from, and a lot of copied and paste code everywhere. Nothing is commented and because everything is mashed together, there is almost no reuse-ability (unless you just copy and paste and edit parts). This ends up being why there is so much repetition of work being done and why a lot of things break (or not work as expected).
Me on the other hand, I would write helper libs that are generic enough that could be used by anyone who is doing a similar task. The problem though is by doing something more generic it takes a bit longer.
I also test/debug my scripts and fix any issues before I feel comfortable releasing. My co-workers? They will release their work and say they have completed it and let the test run. If the next day the e-mail reports anything wrong, they will fix it; else, they will move onto their next task.
I...just cannot bring myself to do that. But in the end, I end up submitting things well past the given deadline.
Help, please? I do not feel very secure at work and I would hate for my stubbornness to be my downfall. (Understand though that I've not had a talking to from my managers regarding my work, so my lack of feeling secure is more me thinking why would they want to keep me when other people can finish the work much quicker?)
TLDR: Having problems at work worrying too much about design and stability. Need opinions on how one balances writing well written/reliable code with time/deadlines. And maybe examples of how one might approach a project.
Tzyr on
0
Posts
When you're asked to do a job, and you're given a deadline, you need to have something to show that you did the work by the time the project is due. The deadline is the most important thing because it dictates how everything else fits together. If your work is being used by another team or department, they likely cannot begin or continue their work until they see how your project is working.
We do this with web stuff at work. If someone has to create a mockup or create an interface, and then another team will examine the interface to see if it fits their needs, then they are utterly reliant on the first team before they're able to begin their work. So those deadlines are the most important. In our case, because it is understood that having something that works, even if it doesn't work perfectly, is more important than starting out with the best possible thing (because who knows what's best until they've used it?), we're deadline focused.
In your situation, it's likely that your perfectionist habits are restricting your ability to finish your work on time. If the completion time was estimated to be too short, then you need to have an outline and the basics up and running by the deadline so you can SHOW someone that the deadline was too short.
A good analogy is like building a house. If you schedule 1 month to build a house, but it takes 2 months, if you have a frame, roof, exterior and floors in, but no walls because the electricity and plumbing is taking more time, that looks a lot better than having a bunch of blueprints and materials lying around. Because it shows that you're completed a portion of the task and the reasons why the project is taking longer is more clear. You can outline why the deadline was too short.
I'm not a programmer so I can't give you tips and suggestions for fixing your own work. But the balance that you're having trouble with is common among people starting jobs. You need to evaluate how you work and see how you can get close to a deliverable you're happy with by the deadline, without turning in junk.
I think you've identified an important set of tradeoffs in the development process: speed vs. reliability, general use code v. one-time throwaway code, etc. There's no "right answer" to these questions, more like constant struggles to strike a balance that works for the task, the team, and the organization.
Of course, from your description I'd agree with you that your team seems to want to live too far down on the "speed" side of the continuum. That sounds like a nightmare, especially for testing. You want your test code to work. It's the goddamn test that other code has to pass, after all. If the test is bad, you either miss bugs (and why write the test?) or you get false positives (meaning you are wasting some developer's time trying to confirm a bug that doesn't exist). Are your 'customers' happy with the work that your group is completing?
As to how to change that culture of quick n' shoddy coding, that could be a tough nut to crack. At the end of the day it might just be a decision your manager makes that you have to live with. That's something that's (somewhat) within his/her job responsibilities, after all - managing the team and the workflow.
Of course, that doesn't mean you should just roll over. You know when an H/A thread starts and the guy is all "I really like this girl, and she's kinda cute, and we talked a bit in art class the other day and I think she might have been flirting with me... how do I know if she likes me?"
and the response is three pages of "Why the hell are you telling us about this? Talk to her!" Well, the same advice applies to you. Have you brought up these concerns with your manager? Obviously you need to behave with some tact, but no decent manager is going to scoff at honest input from people who care about making the team better (and probably saving time in the long run that's wasted on unmaintainable code).
If you need some meditations on this topic that help to have a productive discussion, you might want to read Code complete or listen to the most recent stack overflow podcast, the section on "what makes a good tester."
It sounds like it would slow things down a lot more, but if you can do some pair programming with one of the devs, writing test cases as he writes his code... there will be a brief period of lag while you get up and running, but once you're used to the routine the constant feedback loop and guard against regression means that you get very good results very quickly.
It also means that you can go back and refactor a lot of existing code to make it sleek and re-usable, and your body of tests will catch any errors introduced.
I did this just the other day with a couple of plugins -> Had to have a couple of methods to create an API for working with IP addresses in a database, which were stored as ints, and also create a long regular expression for parsing information out of a Snort alert.
Through the aid of Autotest and Rspec, I wrote both in a little less than 45 minutes, and now I've got a body of specifications and tests backing up my work, so the higher ups won't bitch at me for wanting to put this 'little script' into production.
Maybe it'll take some talking to get this integrated into your process, and it sounds like you may not be in this position since you're in the QA end of things, but it might be good to have a talk with your manager and bring up some of these ideas.
@EggyToast:
Yeah, one of the things I learned earlier in life (programming was not my first profession) was that people wanted to see progress more then anything. I guess I find that hard to do in programming sometimes cause you do get times when it either works or does not work...so unless they look at my code, they won't really see progress.
And yes, that is what I'm struggling with, proving that the deadline is indeed too short. I have to get OT approved but since I cannot come up with a valid reason other than its not done yet (to explain to upper management), it is why I do the OT for free. But even if I did not do it in OT hours, I am still having a hard time justifying why things are taking longer. I guess I just do not have anything to reference off of to show.
But I will try to quantify my work more so that I could then go to my leads and show them why it is taking longer than the estimated time.
@Monolithic_Dome:
I have gone to my leads a few times regarding both my concerns about how long it takes me and also the qualitative work my co-workers have done (not in a tattling way, more a question if I should do work similar to them). The answers I got about the former vary, but it usually came down to stop over thinking/designing. The answer to the latter was that they knew and was probably why I'm still around and that my co-workers have not been promoted yet. Yes, they like how quickly they get things done, but their ego and the fact that every thing breaks...well; it needs a lot of work.
The problem of course is finding that balance...which is definitely hard and not something I remember learning at school. At school, if you had to spend all nighters finishing something...well you did it. But it should not be as restrictive at work.
The main problem I found going to my leads though is finding a reason for why things are taking so long (like I had said to Eggy). Sometimes at the end of the day I look at what I accomplished for the day and have a hard time justifying to myself how little work I ended up doing (what it appears to be, of course). I try to think what I did and it never really adds up. Time seems to just fly (with meetings, helping other people).
And yeah, regarding your comment about it being a nightmare to test. That is exactly why I try to put so much effort into my work. Fortunately a lot of the foundation of our test bed is done by that the project is considered to have failed the test when errors are logged; else the test is said to have failed but it is more a warning. That way it does not sound alarms to the developers that the project is broken, more a warning to the testers why are the tests failing.
Though I guess another thing I should mention is that all of the code that we produce are in separate projects/apps that are run. So even if they are technically inefficient, it fortunately does not effect the main project. But I guess that's what is also bad for because it is not apart of the main project, people seem to care less?
I saw and read a bit of Code Complete, but have not had a chance to fully read it yet. I do pick up books often (both more in depth about a language or api and software design) so maybe I will pick that up next.
Had not heard of that podcast before; will check it out. I do get a lot of answers regarding questions on their site.
@Legionnaired:
Yeah, I have been reading about Test Driven Development (I read Martin's Agile book, the one in C# though I know that he wrote a C++ book too). It was neat reading through a couple of examples of how they wrote a small project.
I have noticed writing code with someone can work well, but I guess it is hard to get out of the habit of writing alone then passing it off.
I will definitely read up on the articles/pages you have linked.
Thanks.
Has anyone spoken to you about your tardiness? Do they recognize that your code is bug free? Maybe they like you because they don't have to go back and fix things, although if you take 4 times as long as everyone else and twice as long as the deadline I doubt it. Are they mad at you? I don't understand why you aren't getting paid for overtime, are you working off the clock at night?
To me it sounds like you aren't really following instruction, they're asking for a test, not a universal test library, you probably need to compromise and just write the tests, I would still debug and test before release but try to get things out on time. It's a hard lesson to learn when someone asks for something you need to fulfill their expectations, not yours.
Have you tried looking for a department or other job that demands more exacting work on the first try?
You should explain to your manager the paradox that is occurring and, without hinting at "maybe we should spend more time on these things", see what they suggest.
What I expect will happen is that they will tell you if you want to make these things reusable and modular, you need to do it on your own time.
we also talk about other random shit and clown upon each other
I do reuse my libs, but it is not uncommon for others to not and that's part of the problem. People seem to just get things done without actually realizing that there are other ways/methods.
And admittedly, in a way you could say that I'm not really following instructions cause the end result they want is a working test. The fact that I designed a re-usable lib does not matter unless of course in the end it saves a lot of work. That's part of what I have trouble with. When I'm asked to write a test that I can re-use my lib, then I can complete the task quickly. The problem is I jump around the tests I need to do which means a lot of the earlier on tests take a while to do. At the end of the project, it should even out (maybe even be more efficient)..but hard to see that early on when I set the foundation.
Especially since the tests we use we will have to use them again for the next project. But that is 12-16 months down the line. Unfortunately I keep moving projects so though my stuff for the previous project is available with documentation...it could easily be missed/overlooked by the next guy who comes in.
One of my co-worker's is my direct lead (though it is more a senior position than lead, he does not manage me) has brought up about my tardiness. He also has said that management ask him if there is anything he can do to help me finish quicker. And a couple times during our progress meetings it does come up if they should re-think the task for it is taking longer than they had estimated. But, it is not like someone is directly saying to me to shape up (unless they are being passive aggressive....)
As to why I am not getting overtime, I get paid hourly and anything over the regular hours have to be approved by management (different management than who assigns me tasks). I need to explain to them why I need to stay late.
If say someone who assigns me tasks asks for me to do overtime, I simply just need to forward that message to my manager. However, without being able to give a good concrete reason to why I am late and why I need to stay (to either manager); I would simply get refused.
I stay late because I worry about both the quality of the work I do and my security of my job. It might be that I am secure, but because of my unique position of what I am (it is hard to explain, but basically I'm a contractor that works for a company through an agency), I do not get progress one on one sessions so I honestly do not know.
As for looking to other departments, unfortunately I can only make a request but with the lack of available positions at the moment, I am out of luck. That and I do not really know if things are better else where. Other departments I've been on, I was kind of forgotten and it was not until the end that my work was evaluated.
@Jasconius:
That has been the impression I get from what I've managed to learn from them already; is that if I want to do things more reusable and modular, I need to do it on my own time. Hence why I work late, and work on the weekends.
But hey, at least its spending time on something that can further my career (what I learn is great), and it feels productive. I just have to make sure I rest as well.
Once you get into a more senior position I'll bet you can put your skills to better use, you just need to get there.
heh I was listening to "what makes a good tester" and one thing that was brought up was about how sometimes you have people who are developers who should be testers, like they spend too long trying to make things working perfecting (they can never get things done remark) where as a developer you need to keep going.
Wonder if that is a hint that I should not be in development ;p
I agree, and I guess it is my stubbornness that is getting in the way. I do work on side projects, but at least when working late, I do not feel I'm wasting time for I am learning something and getting more experience in something.
Which is why I changed to this career, cause at least I feel I am growing with the more I do. In previous stuff that I had done, your career path was set out for you and other than doing the work faster, there was not much to learn (cause the stuff you could say learn/research, other people did that job).
I guess it boils down to how your tasks are assigned or how late in the project it is. Do you get to see the whole project schedule beforehand and know what you and everyone else is working on? If so, reuse becomes a whole lot more useful since you can talk with your coworkers about what the different needs of the project are and design/set up the project accordingly. And if they don't want to bother with that, you can at least design your stuff so you can be reuse it in your later tasks. You'll just need to make sure you can justify the time cost up front before doing any of the work. I'm sure if you estimate that their two week task will take you four, but save an extra three weeks later on, management won't have a problem.
If you get tasks assigned to you piecemeal and never know what's coming up or it's too late in the project, I see no benefit in spending the time to create a generic library which may or may not be useful in the future. In that case, you'd probably be better off keeping notes about what you've done in the past and where you can find it in case something similar comes up. Then at that point you can make use of it by copy/pasting or generifying the code into a library. Trying to create something generic when you're not entirely sure of all of the use cases for it is going to take much longer than just slogging through the task outright.
Two weeks is way too coarse an estimate to have much accuracy. What I'd do first is break it down into individual subtasks of no more than a day each and using those set up daily goals for myself to hit. If the sum of those estimates came out over the initial two week time frame, I'd know right away and be able to let management know there's a problem. It's a lot easier to deal with schedule overruns early than to be constantly letting people know after the fact.
This may also help you with getting overtime and/or your "over designing" of things, since you'll be able to take your mini-schedule to your lead. They'll either understand your justifications for why stuff is needed and give you the green light on OT or be able to help you cut out unnecessary things you've been putting time into and learn what is actually worth doing.
It will also allow me to see if I have time to play with a design (and see if I have time to do extra design).
Keeping notes about what is done sounds good too, cause then I can also see things that I do need to be able to re-use and what might be nice, but not needed.
To answer your question about how I am assigned tasks, no I do not see the whole project. Most of my tasks are given with a couple weeks warning (as in, we need to do the following), but I also get a lot of tasks that might be stop everything you are done, and complete this.
I would say for a good deal of the tasks that you really only need to get it up and running, I do not spend time designing; but I might be cautious of saying something is complete before testing it with a good deal of success. I guess I need to be able to give them the tests that I seem to be concerned about and let them either suggest ideas I could do to deal with them, or they could say that I ignore them until they become an issue.
I have been fortunate that most of my tasks are not depended by other people, but more so the faster I get finished, the faster they see results of the tests.
Thanks for the ideas, Larry.