5 replies to this topic

[coder0xff]

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. Though I'm excited about the project, I'm honestly kind of dreading it. My project is a substantial one, and I'd like to do it right the first time. 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"? I have no problem with reading documentation and reference material, but it only gets you so far.

[ApochPiQ]

There is no substitute for experience.

If all else fails, prototype, prototype, prototype. Throw away anything you can improve on, and do it right the second/third/fifth time.

[Álvaro]

Unfortunately, most of what guides good architectural decisions is experience. To the extent that you have suffered the horrors of bad architectures in the past, you know what kinds of things to avoid.

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.

[Telastyn]

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.

[doeme]

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.

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"?

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.

[Antheus]

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.