the Next Step: Making the leap from Code Monkey to Software Engineering

[sao123]

Background:
Up till now, all of my programming has been a 1-man show, from start to finish, with only minimum required documentation, on local scope projects (1-2 user database projects).

I have a Bachelors Degree from Penn State in Computer Science and Engineering, with only a small handful of classes related to Actual Software Engineering, which was largly an epic exercise in writing papers, and buzzwords.


Task:
Management has came to a group of us "code monkeys" - wishing for us to attempt to form 2 small software teams to take on some larger scope projects, NOT large enough or important enough to outsource to real developers, but still multi-user enterprise level applications.

The group doesnt have much experience in team software engineering principles, but we have not been saddled with a lot of mandates either.

Thus far our only mandates are, we will be developing in C# 2008.net, LINQ, & SQL. Though, I expect to get a few more requirements than this, like possibly a Web Page interface into this app, or Crystal Reports functionality.


What I Need From AT:
Though not set in stone, I believe I am going to be requested to be one of the 2 team leaders. How do I get our team from the 1 man do it yourself coding world, to a team of 4 individuals accomplishing a full software lifecycle.

What software engineering approach is best for a small team of 4?
I know software engineering usually has lots of roles (Project managers, analysts, Engineers, Coding Manager, Developers, Testers) - but we only have a team of 4 people, so we need a simplified but still effective approach to software engineering. Rational (RUP)? Agile? CC? XP? Something else?

We need A good system for project management, to track assigned tasks, and to ensure we are meeting schedules and deadlines. Usable structure & method for a coding repository... (most likely we will be required to use sharepoint)

We have good programmers... but
I need to know how to teach and implement TEAM CODING. How to design a simple standard scheme for naming conventions and in-code documentation. Define a method for workflow...daily/weekly builds, testing while coding, defect documenting, versioning, usable metrics, etc


Point me in some sort of direction.
What you do in your SMALL software team development.
Books to read, concepts to research.

Anything I've glaringly ommitted from my questions...

 

[Jaydip]

Background:
Up till now, all of my programming has been a 1-man show, from start to finish, with only minimum required documentation, on local scope projects (1-2 user database projects).

I have a Bachelors Degree from Penn State in Computer Science and Engineering, with only a small handful of classes related to Actual Software Engineering, which was largly an epic exercise in writing papers, and buzzwords.


Task:
Management has came to a group of us "code monkeys" - wishing for us to attempt to form 2 small software teams to take on some larger scope projects, NOT large enough or important enough to outsource to real developers, but still multi-user enterprise level applications.

The group doesnt have much experience in team software engineering principles, but we have not been saddled with a lot of mandates either.

Thus far our only mandates are, we will be developing in C# 2008.net, LINQ, & SQL. Though, I expect to get a few more requirements than this, like possibly a Web Page interface into this app, or Crystal Reports functionality.


What I Need From AT:
Though not set in stone, I believe I am going to be requested to be one of the 2 team leaders. How do I get our team from the 1 man do it yourself coding world, to a team of 4 individuals accomplishing a full software lifecycle.

What software engineering approach is best for a small team of 4?
I know software engineering usually has lots of roles (Project managers, analysts, Engineers, Coding Manager, Developers, Testers) - but we only have a team of 4 people, so we need a simplified but still effective approach to software engineering. Rational (RUP)? Agile? Something else?

We need A good system for project management, to track assigned tasks, and to ensure we are meeting schedules and deadlines. Usable structure & method for a coding repository... (most likely we will be required to use sharepoint)

We have good programmers... but
I need to know how to teach and implement TEAM CODING. How to design a simple standard scheme for naming conventions and in-code documentation. Define a method for workflow...daily/weekly builds, testing while coding, defect documenting, versioning, usable metrics, etc


Point me in some sort of direction.
What you do in your SMALL software team development.
Books to read, concepts to research.

Anything I've glaringly ommitted from my questions...

Make sure that you all share the same goal.The alignment is the key.Reusability,modularity is very important.Make sure you/team lead understand the software engineering concepts and can explain to the team members.And lastly don't try to reinvent the wheels.

 

[Tweak155]

First off, get very used to commenting. I still suck at it (not that I don't know how to write good comments, I just don't care when I'm fevorishly working on a solution).

Luckily, even with code that has 0 comments, I've become very good at reading what large amounts of code do rather quickly which is a good skill. If you don't have this yet, I imagine you will obtain it as your team grows.

But, if you become the "lead" and there are no standards at your company, you will probably want to identify a code management software early on. Probably not "needed" for 2 man teams, but you should push for it and learn one. It will put you in greater position down the road as the software grows, you will become the SME.

There are packages you can buy for project planning that will guide a software development cycle or document and create your own. If you haven't done it, it is not a wasted investment to adopt an existing one. From there you can make changes as needed as you see what works and what doesn't work. Our company uses Agile, I personally like it. You get to have releases throughout the lifecycle instead of just one major release. You get lots of comments early on and changes can be made before your project is 100's of thousands of lines of code.

Also you'll likely need someone to take on a project manager type role to keep the teams together. To start, one of the programmers can likely do this if you only move forward on one project. But as you get more projects moving, you'll want them to share information and create standards if possible for your company. It saves development time and reduces training. For example, you don't want two different groups creating security protocols that are out of sync if you can help it (sometimes the projects will call for it).

Anyway between e-mails I'm answering and texts, I've lost my train of thought. Hopefully this helps!

 

[beginner99]

1. Usable Doc Comments
2. Code comments in hard to understand parts
3. Source Control, as example mercurial or git
4. Unit Tests!!!

This 4 will help a lot. If you are 4 people in the same office I would not chose any to strict heavy process. Sure something agile whatever that exactly means nowadays.

I personally use mercurial for course control and https://bitbucket.org/ as my online repository. It's free for up to 5 users and unlimited private repos!

It also comes with a built-in issue tracker. I mean it's nothing liek JIRA but it's usable. You can create issues, assign them to someone and you can have them closed automatically if you make a commit message like "fixes issue #5".

I suggest you have a look at it. IMHO VS comes with mercurial support.

 

[veri745]

Mostly what others have said, but

1) Coding spec. Define what naming schemes and formatting is required, recommended, or forbidden

2) Revision control. Define what the developer workflow will be for standard features and bugfixes, branching, tagging, release process, patches, hotfixes, etc. You may or may not need a workflow for each of these things.

3) Unit tests. Choose or create a framework. Track unit test coverage of the project over time.

4) Peer code reviews. I'm a huge proponent of code reviews. I love it when other people provide feedback on stuff I have done, and I think it's a great tool to encourage cohesiveness and alignment among a dev team. There are some cool tools I've used that help with these; I personally like Crucible (Atlassian), but there are lots of others.

You already brought up choosing a development methodology (Agile, RUP, etc). It really depends on the needs and requirements of the project, but I think it's more important for the team to choose something that works as opposed to have it thrust upon them.

 

[Net]

Items to use:

1. Task manager (i.e. Jira) [Break tasks up into improvements, bugs, features, etc.. and enter them into a task manager. Hold a team meeting to assign/chose tasks.]

2. Revision control (i.e. git)

3. Hold tag ups to go over the process of items in the Task manager (I like weekly tag ups, do whats best for the team)

4. Determine your work flow (i.e. Feature branch workflow http://dymitruk.com/blog/2012/02/05/branch-per-feature/)
a. If you do feature branch work flow, do a code review before rebasing the branch into master. If you want the code reviews to be able to take place when people aren't available at the same time then gerrit is good for that http://code.google.com/p/gerrit/

 

[hooflung]

I would say you are being asked to be a software architect not an engineer.

On top of what has been suggested I would add that you write modular code. Never make a method that doesn't need to exist but never write a method that does more than it should. Make sure you code to interfaces as much as possible and look into dependency injection as a way to bootstrap your applications.

Spring is a very good one for java and the .net version is getting pretty useful. It is probably advantageous to adopt SOA so that you don't bake functionality into a single place. Soap and JSON restful services are the bees knees and if you write them to a two phase commit via following XA so you can do global transactions around multiple end points.

With services you can write thick apps, web apps or mobile around them.