This is the first one in a series of 3 blog posts on software development process in the real world. In this series I will talk about 3 broad topics:

• Team member roles
• Development environments and servers
• Steps in the development process

Intro & Background

This blog post series is intended for readers who are somewhat new to software development within a team, or for those who are seasoned developers but want to get a refresher on it or want to take a more systematic look at it.

The content for this series of blog posts actually is an expansion of the talk I gave to Oklahoma State University Computer Science department’s Fall 2015 software engineering class (included at the end of this post). I have had the privilege to give talks to this class in the last several years, each year covering a different topic. I really enjoy doing this because I enjoying interacting with college students, and also I know what I share with them is not something they will learn from school, but will help prepare them for the real world. The things I share with them are the kind of things I wish I was exposed to more when I was in college.

For this year I picked the topic of software development process because I feel like this is a very important topic for any to-be software developers, and unfortunately a college class probably doesn’t do it justice. This has also been a topic I have personally been pondering on for a while now because I see the huge difference a good process can make, esp. when contrasting my past work experience. This is a big deal! It can make or break a company or a product.

Now, allow me to brag on my current employer a little. 🙂 My current company, SST Software, has a very good process in place and we are able to consistently crank out quality software. I’ve learned a lot from our team, and a lot of what I share here is acquired from having worked here for a little over a year. SST is not perfect, but I think the success of our products and offerings speak louder than anything.

In this blog post series, I’d like to use the process used by SST as a spring board, and attempt to give a fairly comprehensive description of what the team members roles are, what the development environments and servers are, and then with those two prerequisite topics already discussed, we will go through all the steps in the development process from requirements gathering to getting the software into users’ hands.

Why Do We Care About Team Member Roles & Responsibilities?

Yeah, I know. This seems like a dumb question because the answer seems obvious: we need a good way to divvy up the work, of course! That’s very true, but hold on, before you dismiss this as a dumb question, or a unnecessary point, ask yourself: Does everyone on your team always know exactly what they are supposed to be doing? Does everyone on your team at least have a general idea on what their teammates are supposed to be doing? Also, does everyone on your team always trust that their teammates are doing what they are supposed to be doing? If a project succeeds, do you know who contributed what? If a project fails, do you know who can be held accountable?

Really, spend some time thinking about these questions. If you have any uncertainty about the answers to any of the above questions, I believe your team has some issues that need to be worked out before you take on a project together. This is because the software development process is such a complex and dynamic process that it is so important for everyone on the team to have clearly defined roles and responsibilities. Otherwise it’s a train wreck waiting to happen.

I’ve seen this first hand from my past work experience. For a small project and a small team, maybe you can get by. For a large project and a large team, you definitely need everyone on the team to know exactly what their roles are. This is true with almost any type of project and team, and it is definitely true for software development teams. Don’t believe me? Try without it and let me know how it goes.

I want to mention here quickly that sometimes for a small team, you will have more roles than people. That’s ok. In that case you will just have to make sure each team member understands that he/she might take on more than one role in order for the whole team to function properly. I believe most of the time as long as that is conveyed to the team member clearly and the extra roles aren’t unreasonable, he/she should be ok with it. What’s NOT ok is one of the following scenarios:

• having no clearly defined roles, but still expect certain roles to be fulfilled by someone.
• having clearly defined roles, which means expectations, but not every role is assigned to someone.
• having clearly defined roles and expecting someone to fulfill those roles, but that person is not aware of it.

So hopefully by now I’ve convinced you that having clearly defined team roles is extremely important. Now let’s talk about what the team member roles are for a typical software company.

Team Member Roles

This is not necessarily an exhaustive list, but I believe it does cover all the typical team member roles in a day-to-day development process. Note that I am not attempting to list ALL the team roles in a software company, only the ones that pertain to the day-to-day development process. For eg, I’m not going to talk about the roles of HR, Marketing, CEO, CFO, and so on, although those roles can have huge impacts on the development process.

Also, in this post I am more interested in showing you the list of roles and what’s generally expected of them on a high level, rather than trying to give you all the detailed responsibilities. I will talk more about those for each role in the 3rd blog post of this series.

• CTO (Chief Technology Officer)
  • Oversees all technological development
  • Leads the technical team, including devs, architects, DBAs, QA, IT
• PO (Product Owner)
  • Owns a software product.
  • Develops and maintains the roadmap of a software produdct.
  • Oversees all of the feature requests and bug reports of a software product.
  • Interface between users and internal team.
  • Bridge between business and technical teams.
• BA (Business Analyst)
  • Analyzes and documents requirements.
  • Works with PO, users, and technical team to create the requirements.
• UI/UX designer (User Experience Designer)
  • Usually graphics designers, but UX is more than just graphics.
  • Works with PO and BA to create UI mockups.
  • May create both low and high fidelity UI mockups.
  • Document all UI/UX requirements and convey to other team members.
• Software Dev (Software Developers/Engineers)
  • Programmer: An organism that turns caffeine and pizza into software. (programmer T-shirt)
  • Understands all requirements, both functional and non-fuctional requirements.
    • Functional: what is it supposed to do?
    • Non-functional: how is it supposed to do it? how performant? how secure? what’s the deadline?
  • Write code and make it happen.
  • Review each other’s code.
  • Writes tests: unit tests, integration tests, regression tests, etc.
• Technical Lead
  • Each team has a technical lead.
  • usually each team focus on one platform or product. For eg, Windows, web, iOS, API, etc.
  • The tech lead is involved with the gory details of code construction within the team on a daily basis. The architect is not necessarily doing that, but more concerned about the bigger picture.
  • The tech lead makes sure tasks are written for each sprint and manages the statuses of those tasks on a daily basis.
• DBA (Database Admin)
  • In charge of the overall database architecture and health, and performs maintenance and optimization of our databases on a daily basis.
• Database dev
  • Creates db designs, tables and sprocs
• Softare Architect
  • Architect of a particular software project or product.
• System architect
  • Company’s overall technology system architecture.
• QA (Quality Assurance)
  • Testing software implementations to make sure they meet all requirements.
  • They are the final phase of testing. They decide whether to give the green light to deploy software into the wild.
  • Their testing is more comprehensive and have lots of real-world like test data.
• IT (Information Technology)
  • Responsible for hardware and network infrastructure.
  • Works with dev teams to deploy software to our production environment.
  • They should be the only department that has access to production resources in order to maintain security and production resource integrity.  Single point of contact. No room for guessing.
• Customer Support
  • Helps our customers resolve their issues with our software by phone, email, screensharing, etc.
  • Also works with POs and BAs to report bugs and document feature requests.
• Contractors
  • We pay them to do things we don’t want to do or shouldn’t do.
  • Usually this is b/c we are not experts at everything. We pay contractors to do what they are good at.
  • Also a lot of times hiring contractors is cheaper than trying to do it ourselves.

Wrap-Up

If you work on software only by yourself, this blog post doesn’t offer you as much value because most of the things I talked about above are intended for readers who work in teams, although as a lone developer it’s probably good to have your own process too. But you are probably a minority in the developer community.

To those of you who work in a team, if you are new to software development, or just want to take a more systematic look at it, I hope you now have a better understanding on what the typical roles are and why it’s important that we clearly define those roles.

Stay tuned for the next blog post on Development Environments & Servers, which is also a very essential topic in the overall development process.

Here’s the slides for the talk I gave.