Login/Register
What's most important when you need to establish a software development infrastructure in your company? [closed]
Asked Answered
Solved infrastructure
E

10

6

Let's say you work for a huge company which suddenly decides to do custom in-house software development. Additionally, they want to be able to offer successful developments to their customers as well (if any).

Now you are in charge of it.

What would you see as most important to build a successful software development infrastructure?

  • flexible to future growth
  • flexible on used technologies (projects with c, java, .net, web, mobile, ...)
  • What kind of tools (source control, forge, ...), hardware (virtual, seperate dev & production, ..), processes (guidelines, code reviews, ...), etc.

UPDATE: Please don't answer that you need the right people and the right tools. This is exactly what i am looking for.. What are the right tools and what people of what type would you hire first to join your team? Think of it as you will be the lead of that development.

Etymon answered 20/1, 2009 at 14:52 Comment(2)
It's going to be difficult to provide detailed advice on who to hire and what tools to buy without knowing what industry you're in, what kinds of applications you'll be developing, what operating systems you have to support, how large a team you can afford, etc. – Hardner
want to start with a team of 5-10 members ... developing mainly for windows OS in the beginning. industry independent – Etymon
H
10

Set yourself up to pass the Joel Test with at least a score of 10.

Homogenize answered 20/1, 2009 at 15:5 Comment(0)
B
5

Someone in charge who knows what they're doing.

Bicentennial answered 20/1, 2009 at 14:52 Comment(0)
M
5

I think having the right people is going to be the most important. Nothing else will matter if your programmers stink.

Mcallister answered 20/1, 2009 at 14:55 Comment(0)
H
3

Obviously, there are lots of factors, but here are the ones I'd say are crucial:

  • Hire smart people (and pay them what they're worth)
  • Select good tools appropriate for the kind of development (don't go for cheap tools)
  • Establish version control system and policies
  • Establish testing mechanisms and policies
  • Don't be afraid to outsource the stuff you don't know how to do
Hardner answered 20/1, 2009 at 14:56 Comment(0)
Z
2
  • Get the best people for the job. If they aren't willing to pay for the best available, or give you a hard time over your personnel budget, you're off to a bad start.
  • Get the right tools for the job... software, hardware, support contracts from your vendors, etc.
  • Establish procedure early on for your development life cycle, and make sure that you have the people in place to make use of it. This is everything from how you evaluate Opportunity Assessments to Development, Testing, and post-production support. Make sure you have the people and the tools for each part of the life cycle.
Zoosporangium answered 20/1, 2009 at 15:4 Comment(0)
G
2

Dont try to be flexible in technologies. First start by focusing on one technology (Java, .NET, whatever...) and then move to other if you need to. You will be able to solve problems using any technologies, but it is very hard to find people good in many technologies.

At the infrastructure level, Source Control is a must. Continuous integration is a plus. Take time to put in place a standard project layout that you will be able to evolve. It make it easier for developers to switch projects. Take time to put in place a good build process (Ant, Maven, in the Java world). Integrate your build process with your IDE so that developers dont have to wait 5 minutes to deploy their project every time they want to test a code change.

Ghoul answered 20/1, 2009 at 15:4 Comment(2)
but what if you want to offer different technologies. You let project teams develop in different technologies but you offer them an infrastructure which is tech-independent (source-control, forge system, guidelines..) – Etymon
If it's part of the requirements, then it is part of the requirements. But usually, the best technology is the technology that your developers know the best. And you rarely find developers who are very good in multiple techs. – Ghoul
J
2

I agree with Guillaume: If you want to build a department from scratch, you need to focus. You need to build your team, have everybody grow into their new responsibilities, get to know each other etc. Trying to go into too many directions at once is the direction towards failure.

So, identify the technology you want to develop in. Since the primary goal in your example is in-house development, the in-house requirements will determine your decision. Build your team with that primary goal in mind.

For in-house development, you need at least two people who already know the company and its processes. (Two because one will definitely be ill or on holidays when the first major crisis hits you). On the other hand you need some outsiders, who are not entrenched by the "we have always done it like this" mindset, who can think out of the box. Those should also be at least two people, for the reason stated above. Your job as the team leader is to balance those two groups and integrate them into a team.

For future growth, always think in terms of organic growth. Do not increase the team size by 200 %, hire one new guy here and another guy (or gal) there. Slowly build your team. When you take on a new project, always think of expanding your teams expertise. Try something new with every project. That can be a new source repository, an automated daily build process, a new system to write specifications or documentation, or even a different technology (for example Java when you usually develop in .Net, Delphi or C++). Just make certain you never try to make a big leap in an important project. (I once worked for a company who decided to switch from VB 6.0 to .Net for the biggest project they had ever attempted before. They survived. Barely.)

That way your department will slowly but constantly expand its capabilities. Then when the opportunity presents itself to do development for an external customer, you will already have accumulated most of the knowledge you need in order to pull it off.

Oh yes, and smacl is right, too: You need solid QA/QM if you want your department to survive long term.

Start laying out (and follwing) your QA rules from day one. Keep them as short and flexible as possible. Add what you discover to be missing, and throw out what proves to be unnecessary or impractical.

Not sure this is what you wanted to know, but I felt the need to say it ;-)

Jacobsohn answered 20/1, 2009 at 16:6 Comment(0)
S
1

Develop a strong QA strategy, including acceptance criteria and change control. Preferably keeping it lightweight to suit internal clients. In addition understand how to carry out requirements analysis, expectation management, and resource management.

Put another way, don't just wing it to create crappy solutions that waste more time than they save and are impossible to maintain. Take time to think about what you want and need, how you can achieve it, and what it is going to cost.

Sirius answered 20/1, 2009 at 15:39 Comment(0)
V
1

I will offer an answer more focused specifically on coding and the developers / architects role in addition to the previous answers on teams, version control, qa etc. which are of course all important.

Many of your decision is very dependant on your specific business and software structure (a single product code base, SOA, many projects etc.) But in general you should always spend significant time up front developing Core Software Infrastrcuture that will pay huge dividends during the SDLC.

Software infrastruture

  • Coding Naming Conventions Exception

  • Handling strategies Logging

  • Strategies Settings and Configuration

  • Base classes and Helper Classes

  • General Architecture and Layers

    (Presentation, Facade, Domain Entities, Data Stores etc.)

  • Design Tools such as UML 2.0 Requirements

  • Management / End user interaction

There are tons more, but these are certainly some basics to think about. All of the successful projects I have been involved with incorporated decent software infrastructure. I will also note that many of the project that fail have a common theme... lack of a common infrastructure in place. In most cases these failed projects are lead by a non-technical person that think they can simply throw a bunch of ideas at a few programmers and expect them to deliver in a few weeks.

Bottom line, you need to invest some up front planning and prototyping to ensure success in the long term!

Good luck.

Raiford
www.blacksaber.com

Vaunting answered 11/7, 2009 at 19:5 Comment(0)
R
0

The first persons you should hire should be experienced senior level professionals. Then build up from them / with their input. Add the junior people later.

Redpoll answered 20/1, 2009 at 15:51 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.