Mitigating the Effects of a Learning Curve
Members - Reputation: 225
Posted 09 April 2012 - 07:38 PM
Moderators - Reputation: 19913
Crossbones+ - Reputation: 18613
Posted 09 April 2012 - 08:12 PM
I don't claim to have enough experience to be confident I can avoid the types of messes you fear, but If I can try to transfer anything that I have learned over the years, keep things simple.
Crossbones+ - Reputation: 3773
Posted 09 April 2012 - 08:26 PM
Are there any tips or tricks to help avoid making poor architectural and coding decisions
Outside of 'more experience' and 'prototype it first' (which are both excellent) remember to ask around. You're likely a member of a team, and that team likely has experience with the technologies you're using. If you're on a team that doesn't have experience with the technologies they're using... time to get that resume up to date because someone forced technology on a team or hired a bunch of the wrong people or your team is being foolhardy. Whatever the cause, that scenario will only end badly.
Members - Reputation: 1127
Posted 10 April 2012 - 06:00 AM
I'm a professional developer, but I find myself in a position where I'm using technologies, APIs, and languages that I have little experience with.
I mean no disrespect, but this sounds as if you are not the right man for the job. If your are on a team with someone with more experience on this, peer-developing where the more experienced one reviews the code of the newbie might help.
Aside from depending on experience and prototpying, I would say aim to use as many known and prooven patterns and technologies as possible. Try to figure out what standards there are for your problem or which APIs are considered quasi-standard. Also looking into the references section of a library and checking out what kind of products where realized with this technology to figure out what it can do. And for the last, if you are not familiar with all this stuff, document your code well, aim for simple solutions and be prepared for a truck load of refactoring.
Are there any tips or tricks to help avoid making poor architectural and coding decisions, so I can avoid having to go back and redo things once I figure out the "proper way"?
Members - Reputation: 2409
Posted 10 April 2012 - 06:44 AM
I mean no disrespect, but this sounds as if you are not the right man for the job.
"Guys, we just closed a new contract, it's due in 2 weeks. They want MongoDB, backbone.js and node.js. I know we're a Java shop, but these new things are the bestest thing ever and everyone is using it and it's the cutting edge. Also, we'll need you to come in on Sunday."
I'd like to do it right the first time.
Perfection only angers the gods.
In project management terms, if you can get it right 100% of the time, the project is either way too trivial or you spend impossible amounts of resources on it. And most valuable parts of the project cannot be gotten "right", they are transient, fungible and soft and require good response to feedback to pin point the sweet spot.
All you can do is hope that your stakeholders understand current competence levels and will compensate for lack of experience or be able to mitigate the effects of learning and mistakes associated with it in final product. Most helpful is frequent feedback focused on final value - what the project is supposed to accomplish. Worst you can have is trying to follow the todo list and insisting on rigid deadlines with no consideration to actual state of development.
If there are no major stakeholders and you get control of these aspects, then first lose the perfectionist attitude and instead adopt that of a student. Go in small steps, make no assumptions, be humble and correct mistakes as they come up. Celebrate the small victories. But, make daily/weekly goals that must be met. The moment you do, walk away from that part and never touch it again. If you do, having learned much in mean time, you'll be appalled at the quality and will want to rewrite it. This temptation will kill any progress, since first few weeks or months of learning make you go through wild changes in style and approach to problems.