0

I have been given a huge task of migrating few functionalities from jQuery to AngularJS. I have been pretty good at Angular by now. But I want to dive deep and create futuristic, sound architecture. BAs are seating on my neck, wanting to get my tasks as quickly as possible. I prefer doing something once and right vs keeping on patching existing functionalities. And with this attitude, I always keep working more than necessary. Am I missing something? Am I having right approach or am just not convincing enough BAs my point. What's the best approach, in your opinion

Thank You :)

1

2 Answers 2

5

As a developer you should give estimates about the time it will take to do something along with fully explaining the consequences of the various choices in terms of technical debt.

However, if you are supposed to get something done in a week and that is possible (with the associated addition of more technical debt) that is not something you, as a developer, make the call on. The managers, architects, business analysts, and clients are the ones that decide which path to follow. If they are ok with adding to the technical debt of the project, thats fine.

Yes, it is wonderful to sit down and craft some beautiful code that fits an ideal framework and will be beautiful. However, if that doesn't fit within the timeframe for the project, thats not what you should be coding. You are wishing to be a painter painting the Sistine Chapel, and instead being paid to paint a fence... thats ok, fences need to be painted too... but don't paint a fresco in the fence.

Joycoding is a fun thing to do, but it doesn't always align to business objectives.

1
  • Its hard to accept. But its the fact. Thanks
    – om471987
    Jun 2, 2014 at 20:51
2

" BAs are seating on my neck, wanting to get my tasks as quickly as possible."

So what? What happens when you don't deliver when they want? Are they setting the schedule or do you. Hopefully, you have some control over determining the quality of a feature and get some consensus on what it means to be done.

Give an estimate and keep them informed when you will not be able to deliver. Let them know the more they interrupt you asking when things will be done, will only make the project take longer.

They should have some idea of the complexity and length of time it took to create this functionality the first time. Not that they can come up with specific times, but you will need to explain if you do not deliver in a "relative" time frame. Example: If feature A took twice as long as feature B in the old language, you would need to explain why it may take you 3 times as long to build B in the new language as you did with feature A.

Not the answer you're looking for? Browse other questions tagged or ask your own question.