Constrained by technology and time - Solution?

S

shauntir

Well-Known Member
Joined
Sep 11, 2013
Messages
457
Reaction score
0
Location
Durban
So, we're working on improving a current process.

However, I am constrained by both time and other technical decisions taken by other team members.

Though, I have a different solution and possibly one that requires more time + a fresh start, it would be more elegant and better gains in performance and maintainability.

Unfortunately, I can't change the decisions made even though I've tried over 3 times. Would you as a developer do what is told and secretly write out the better solution in "spare" time or would you just forget about it?
 
Raise objections, in writing, to all concerned parties. If your request is denied, just go ahead with what was asked of you. Usually the best business decision is not the same as the most elegant technical decision: getting the "quick win" deployed fast is often preferable to getting the perfect solution out late. It may mean the difference between getting additional funding and getting the project canned.

EDIT: what is the project timeline and how long would the rewrite take relative to the requested solution? What is the most probable date at which the project will be updated again?
 
Well, I've never done formal (in writing) objections before but I guess there is a first for everything.

The estimated time for is early March due to the need for the use of the tool in the middle of March. The re-write would possibly take 2 full months. So I essentially have a month to get performance gains.

However, my manager just had a chat to me saying he wants to get a high level overview first and then we can break it down in terms of technology etc. That way, we could possibly meet deadlines while improving architecture.

I'm hoping for a positive change this time around. Really don't want to code around a dirty current solution.
 
Yeah you'll get over this thinking in time. Just get the job done for now and if there is down time later maybe ask if you can rewrite some modules etc.

I came across an article many moons ago that laid out the advantages/disadvantages of continuing to patch an old application vs rewriting the application from scratch. The one thing that always stuck in my mind was that over time many of the bugs that pop up in the old app have been sorted out where as in a new rewrite you are potentially opening yourself to lots of new bug fixing.

I have gone the route of a rewrite before and if you are working on a medium to large app you are opening yourself up to a world of hurt. Even if you are intimately familiar with the applications code you will miss things that were previously discovered as mistakes in logic or processing. I was especially into the idea of rewriting apps from scratch when I was a junior-mid dev as it (a) eliminated me having to get to know all the code structures currently in place and (b) I thought I could do a better job than the previous person. I've learned that 95% of the time there is no need to make things better than they currently are, even if the current technologies allow for it unless it is of absolute necessity.

What I've outlined above may not necessarily be applicable to your current situation but still good food for thought. Always choose wisely when deciding to go with the flow or going against the grain.
 
Last edited:
You've tried, it's frustrating that no one cares (trust me I know...), so why should you care?

Just do as you told and get your paper son. Code the solution that you want to implement in your free time just to gain the skills, see that as your own personal challenge but don't implement it at work (This is purely for your own knowledge).

When the time is right and you are more confident with your skill set, job hop to a other company that values your new found skill set.
 
I'd write it in my spare time if the proposed solution really sucked - you are there to make quality software, not friends.

That said, once I've written it I'll carefully time and plan introducing it to the team, if at all. You have to "manipulate" the situation just right - if you get what I'm saying. There is no point in pissing them off just to be shot down a fourth time.
 
Last edited:
Even if "Writing a better solution in spare time" which could in fact be better (given the use of better technologies without inducing the cost of time and money for your company or project, as well as having it understandable for your fellow developers, readable, well-documented and maintainable), it doesn't necessarily mean in normal business processes that your solution would replace the current solution. I'd say, mitigate the damage on your current solutions and get a well-formed refactoring, documenting and maintenance plan for your current solution.
 
Just...if you do decide to write it in your spare time - TELL NO ONE. If the current project misses a deadline and they found out you were "moonlighting" on your own solution...problems.
 
Suck it up. You stated your case. When it fails, don't gloat. Help fix it. :)
 
Forget about it, development is not always about perfect solutions but getting something workable to business within constraints of time, cost & resources. Plus you've already stated your opinion covering yourself if something goes wrong hehe
 
Definitely some good food for thought here.

The biggest challenge here is that this is just a piece/component of a much larger system.
It's meant for batch importing and applying business rules to create the entities. So the business process/use case for this component is high performance and processing of large batch files.

The thing here is that the previous dev's have been through a few iterations and performance has actually decreased over the last 6-12 months. So the points of view are that we have another iteration but still try and use some of the code that exists. My point of view is that those bits are exactly what has caused the decrease in performance.

Now I certainly agree that a re-factor is better than a re-write in most instances. But here, I'd say we in-fact need a fresh start simply due to past iterations not working as expected. The way I see it from a business perspective is that continued re-use of current code could actually hinder business operations due to loss of company-wide productivity. Investing in a "fresh start" has the advantage of breaking out of current code and mistakes and take the opportunity to improve without the technical debt that exists.

Having said that, I think I am getting a fair compromise now since I think I may get the opportunity to break out of some old code. But I'd have to agree for now that it's probably not feasible for my career to do this in my spare time since I could get in trouble or not even use the new code base...
 
shauntir said:
The thing here is that the previous dev's have been through a few iterations and performance has actually decreased over the last 6-12 months. So the points of view are that we have another iteration but still try and use some of the code that exists. My point of view is that those bits are exactly what has caused the decrease in performance.
Click to expand...

From what you have said it appears that the team is about to start another iteration in the hopes that performance will be improved, i.e. without knowing the actual cause of the impacted performance.

Rather than refactor I would consider - as a first step - adding performance logging (Enterprise library / log4net / whatever) to the existing codebase.

Then, when you have some indication of the reason for the performance bottleneck(s), plan your next step based on the logging results.

It might well be that (as an example) the problem lies with an inappropriate database schema, something which no rewrite will solve.
 
Last edited:
rrh said:
From what you have said it appears that the team is about to start another iteration in the hopes that performance will be improved, i.e. without knowing the actual cause of the impacted performance.

Rather than refactor I would consider - as a first step - adding performance logging (Enterprise library / log4net / whatever) to the existing codebase.

Then, when you have some indication of the reason for the performance bottleneck(s), plan your next step based on the logging results.

It might well be that (as an example) the problem lies with an inappropriate database schema, something which no rewrite will solve.
Click to expand...

Best part is that we know where the bottlenecks are and we use NLog. Also did SQL profiling. Guess what? Sometimes trying to do the right thing is better not done when the environment isn't conducive to it.

Guess I fall into the plan and develop developer and some others don't...
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X