Really Young Software Architect Question

Question

Hi,

I am a really young software engineer/QA Team leader. I have been developing software for about 2 years and for 1 of those years I have also been the head of the QA team at a software development company. Currently I am still working as the QA team leader/software engineer for QA tools. Recently I have been invited to join a group of friends and associates who would like to start a software company. They want me to be the architect/tech lead of the software (a special chat client written in Java is all I can say about it). I am very good at learning under fire and I learn a great deal by doing. However, I worry that my lack of experience will cause the project to fail (or at least be developed poorly). So I am wondering would you suggest I take the position, do my best and learn as I go? Or would you suggest I refuse?

If you would suggest I take the position would you please provide one or to resources that would be good for a beginning Java Architect?

Thanks, In advanced.

Answer 1

1. Strive to be the dumbest guy in the room.
2. If it makes you sick with fear, do it. If it makes you sick with dread, run away.

Answer 2

You should express your thoughts to your new team. The fact that you are open about it is a big plus i would say. Do your best and keep your focus - experience is not everything, especially when you are aware of your shortcommings!

Answer 3

The mythical man month & Peopleware are the 2 books you NEED to read.

Answer 4

I wont tell you to do it or not, but...

I will tell you that if you want to really improve your skillset and advance in your career, you'll have to take risks and leave your comfort zone once in awhile.

Also, as Developers even though we are more often Optimistic about projects/timelines, we are also often Pessimistic about our own skillsets/abilities and focus on what we don't know rather than what we do.

If you have question, you'll need to discuss this with your potential business partners.

Answer 5

Since you used the words Java and architect in the same sentence, may I suggest the study materials used in the SCEA certification? In particular, I've found Core J2EE Patterns a really helpful book for thinking about bigger-picture architectural issues.

Answer 6

Be open with everyone else in the group and make sure everyone is aware of the risks and understand what the "worst case scenario" is. You also need to be comfortable with all the extra time you'll be putting in over the duration of the project getting up to speed technically.

Also ask yourself if you can financially make it if the project does in fact fail.

If everyone's still on board, sounds like a good learning experience!

Answer 7

Speaking as someone who made the jump to be an architect at a small company I think the following points might help:

1. You know more than you think. Just because you have never been an architect before doesn't mean you don't know enough to be one.
2. As an architect you always need to be learning and keeping abreast of trends and technologies. Be prepared to do that.
3. Listen. Team members will have good ideas that challenge all of your prejudices.
4. Especially in a small company you are going to have to be aware of politics in an architect role. I wasn't aware enough and got burned as a result. This may affect your friendships.
5. Small companies can go under surprisingly rapidly. Plan for this and don't have financial commitments that mean that you can't be out of a job for a short time.

Answer 8

I would not worry so much about being the potential cause of the company's failure. Be up front about your concerns, but temper that with your ability (and desire) to learn.

You owe it to yourself to vet the financing and business arrangements of the founders of the company. I'd say it's far more likely that the company would fail due to "business" reasons, rather than technological reasons.

Answer 9

If you can join the group without having to let go of your job, that would be great. But if you have to choose which way to go and which one one to let go, only you can make that decision. Follow your heart and you will never get lost.

Answer 10

As a team leader, your most important asset is not your experience, but the team you work with. If you know and trust these guys or you get to hire your own team, then by all means, go for it. Read a book about good hiring first (Joel on Software has a good passage about it) if you're going to do any hiring.

You're asking about it on Stack Overflow, so you at least have the right attitude about it. Ask for help when you need it. Don't try to overcompensate your lack of experience by not talking about problems. Just because you don't know the answer to a problem doesn't mean an experienced manager would have either. Check your ego at the door and get the job done. You'll be respected more for that anyway.

If you're coming into an entrenched team with problems and issues all its own, then that's when being an experienced manager really comes in handy. This sounds like a perfect opportunity for you to me. You're never going to be experienced as a manager, without managing.

Answer 11

Based on what you said so far, this project will fail. Heck, most new projects fail. If you're ok with that, then go for it! It'll be a good learning experience for you :) Just be sure you don't lose close friends over it.

Answer 12

There are not many useful, independent resources on software architecture. Once you filter out the vendor marketing and hand wavey ivory tower stuff, there seems to be little in the way of practical advice.

One good one is Coding the Architecture which concentrates on hands on architecture, and has a fair amount of information for developers making the transition to architect (full disclosure - I have been involved with this in a small way).

Also, there is a simillar question about architecture blogs with some very good answers.

Answer 13

As a team lead, you need to be good at getting the best out of your team, as well as learning on your own. By improving your own skills 100%, you can increase your team's productivity by 10%. By improving the team's productivity 100%, you improve it .. 100% of course.

Your value to your friend's startup is not just your pure coding skills, but also that they know and trust you as a partner. Obviously to them they feel you can contribute some real value, so my suggestion is that you "fake it until you make it" :)