4 ms·

Ask HN: Advice for sole dev on massive project

8 points by jfaucett 14y ago

Hey HN, I'm reaching out to you because I know you have the experience to help more than about any other community online. I'm a fairly experienced developer, but this current project is pushing me beyond my limits. Its already launched and for a multinational client. The client is in 40+ countries and they want to consolidate their brand image by unifying their subsidiary websites into one cohesive website. The standard "big company" deal where you are geolocated and automatically sent to a subsite for your culture like ea.com, except /en_UK/, or /en_US/ instead of just /en/. Each subsite will be partially manageable by all the countries (for country specific news, etc), but the majority (90%) of the content will be managed by parent company. Each country will have an optional shop system, which is integrated into the website, but some shop data such as product names, images, will be managed by the parent company. Also, because of the design they have clicking on a link and going to an external shop solution or changing to a different url is not an option, and sites/sites-with-shops have to reside within these sub directories integrated into an amazing design(the Graphic Designer is great) but is not something that is easily implemented in any CMS I know of. (I'm talking lots of js/AJAX calls). Another problem, is that all this must be integrated with legacy databases, and different countries current shop systems etc. I've already built the site and launched in a couple countries, and everything works fine, its secure, and fills the requirements. But I'm having difficulty managing this as one person already and more sites are just going to come (a lot more). Since everything is already built and all the problems (implementation not content management) have been solved, I rebuilding would be fairely quick, and I do have a break now. I apologize for the length and look forward to any helpful advice you can give

runawaybottle 14y ago
I'm no genius, but I think you should hire a freelancer or two to help you out.
cshipley 14y ago
It sounds like your main concern is there is more work than you can get done in a given day or week. Yes? If that's so, there are really only two things you can do. Get some people who can help you, or somehow reduce the amount of work you have to do. (Or both) My advice is to talk open and honestly to the client. When you do, talk about the risks in terms of time and money. Have a list of things ready that contribute to the risk. (Some of the things you listed above) What is your business relationship with them? Freelancer, contractor, or fulltime. Are you the only person working on this? Depending on that, there might be some other things you can do.
acesubido 14y ago
Take a step back, breathe and relax. Set it in your mind that the company you're working for has been running with or without you. Take the burden off your shoulders and clear your head. After getting some peace in your mind, you can take action: The first thing you have to do is to tell your client/boss, without all the computer-techy talk, the situation you're in and how it's going to actually affect them. Clients get pissed off not because things don't "work" or the user experience is "broken". Clients get pissed off because they expected them to "work" and the experience is "nice". Clients have expectations, and most of the time (for non-techie clients), they have unrealistic expectations. Set their expectation and make them understand the ramifications of having ONE guy working on such a massive undertaking under your specific circumstances. After you do this you'll find that it's much easier to breathe in and actually work. In goodwill, they will set aside time and plan things to actually help you, because they know in the end it will help them. Next steps are usual dev protocols: 1. Get it in version control with a dead simple bug/issue tracking system. 2. Always write good commit comments. 3. As for documentation, do it incrementally. Write small bits each time you work with the app, or each time you deal with your build/deployment process. It will compile into good documentation later on. If possible get your documentation into version control as well. I highly recommend that you do these things and produce a consistent flow of routines in your work before getting other people to help code with you. It doesn't help when you have another person sitting around burning precious time figuring out things as he goes along the way. On-boarding them without those 3 things listed will be hard, and it will put off a good amount of time from things that actually need attention. If you're implementing Agile on a personal level, make sure other people are on-boarded with it. You'll find that adding people will be much easier. The cost of logistics regarding adding additional team members rises higher than expected if the development workflow and environment isn't established. You'll burn time on-boarding good developers, you'll burn even more time on-boarding mediocre developers (I've personally experienced this in my previous work). Hope this helps.
luckystrike 14y ago
From my own experience, I know it gets hard sometimes working as a solo developer when you don't have anyone else around to discuss the technical details. If you want to bounce off ideas or discuss anything related to this project with someone, please feel free to contact me. I'd be happy to assist you in my free time.
teyc 14y ago
Given this is a multinational, it is reasonable for you to come out with an overall roll out strategy. In any complex project, you should expect implementation costs to be a certain percent of development costs. Develop a project rollout template, detailing timelines and resiurces. Then train up people who can assist you with this. Remember, you dont scale but algorithms do. On top of it, unless you are planning to stay awake 24 hours, you will need a support team to span those time zones. If there's existing IT teams they need to be trained.

8 points by jfaucett 14y ago

runawaybottle 14y ago

I'm no genius, but I think you should hire a freelancer or two to help you out.

cshipley 14y ago

It sounds like your main concern is there is more work than you can get done in a given day or week. Yes? If that's so, there are really only two things you can do. Get some people who can help you, or somehow reduce the amount of work you have to do. (Or both) My advice is to talk open and honestly to the client. When you do, talk about the risks in terms of time and money. Have a list of things ready that contribute to the risk. (Some of the things you listed above) What is your business relationship with them? Freelancer, contractor, or fulltime. Are you the only person working on this? Depending on that, there might be some other things you can do.

acesubido 14y ago

Take a step back, breathe and relax. Set it in your mind that the company you're working for has been running with or without you. Take the burden off your shoulders and clear your head. After getting some peace in your mind, you can take action: The first thing you have to do is to tell your client/boss, without all the computer-techy talk, the situation you're in and how it's going to actually affect them. Clients get pissed off not because things don't "work" or the user experience is "broken". Clients get pissed off because they expected them to "work" and the experience is "nice". Clients have expectations, and most of the time (for non-techie clients), they have unrealistic expectations. Set their expectation and make them understand the ramifications of having ONE guy working on such a massive undertaking under your specific circumstances. After you do this you'll find that it's much easier to breathe in and actually work. In goodwill, they will set aside time and plan things to actually help you, because they know in the end it will help them. Next steps are usual dev protocols: 1. Get it in version control with a dead simple bug/issue tracking system. 2. Always write good commit comments. 3. As for documentation, do it incrementally. Write small bits each time you work with the app, or each time you deal with your build/deployment process. It will compile into good documentation later on. If possible get your documentation into version control as well. I highly recommend that you do these things and produce a consistent flow of routines in your work before getting other people to help code with you. It doesn't help when you have another person sitting around burning precious time figuring out things as he goes along the way. On-boarding them without those 3 things listed will be hard, and it will put off a good amount of time from things that actually need attention. If you're implementing Agile on a personal level, make sure other people are on-boarded with it. You'll find that adding people will be much easier. The cost of logistics regarding adding additional team members rises higher than expected if the development workflow and environment isn't established. You'll burn time on-boarding good developers, you'll burn even more time on-boarding mediocre developers (I've personally experienced this in my previous work). Hope this helps.

luckystrike 14y ago

From my own experience, I know it gets hard sometimes working as a solo developer when you don't have anyone else around to discuss the technical details. If you want to bounce off ideas or discuss anything related to this project with someone, please feel free to contact me. I'd be happy to assist you in my free time.

teyc 14y ago

Given this is a multinational, it is reasonable for you to come out with an overall roll out strategy. In any complex project, you should expect implementation costs to be a certain percent of development costs. Develop a project rollout template, detailing timelines and resiurces. Then train up people who can assist you with this. Remember, you dont scale but algorithms do. On top of it, unless you are planning to stay awake 24 hours, you will need a support team to span those time zones. If there's existing IT teams they need to be trained.