SE for a startup company
Author
Heya, I'm looking for some experienced opinions on how to improve the software-engineering processes for a newly formed company.
---
I, myself work as programmer and I've worked with the others in the team for some years now, but I feel that we lack the (programming-related) organisation to take on a larger project in the future - we have a schedual, long-term deadlines, priority lists and so on but we haven't adapted to any specific process model (partly because we all work on a distance and many models don't take any consideration of that), no standards (except for coding style), no outspoken ways of testing code, etc...
So, why don't we just fix all the problems I've mentioned? Well, we're still very productive at the moment and I feel that people are uneasy about changing how we work. "If it ain't broken..."-attitude. But I feel we have the need for it, for the future projects if not for the present, and even though it would mean that programmer-time will be lost from the current project.
I've been looking for some guidelines on where to start, but since I'm not sure what I'm looking for, it's proven to be quite difficult :/
---
So, I guess the question boils down to this: how do you people use SE to improve the way you make games?
Its quite easy to get started with unit tests. I introduced tehm to my company just by downloading CPPUnit and writing some for a new class I was working on.
If your developers don't want to write the unit tests before they write code, no problem:) just ask them to write unit tests before they commit their code. To try and shoehorn everyone into test driven development often won't work. You need to understand that everyone works differently and imposing one system on everyone will probably lower productivity:)
Cheers
Chris
If your developers don't want to write the unit tests before they write code, no problem:) just ask them to write unit tests before they commit their code. To try and shoehorn everyone into test driven development often won't work. You need to understand that everyone works differently and imposing one system on everyone will probably lower productivity:)
Cheers
Chris
/Disclaimer: Just finised up a SE class in college, so I'm far from a professional or expereinced in the real world sense [wink]
Read over and learn the TSP and the PSP. That was the first thing that we had to do in our SE class this year, and after going though, myself being the project manager, it is very useful! If there's one thing that I learned from that class is that it's all about organization, communication, and standards, all of which you say your group lacks for the most part. Know that it's not easy to do, but it should come along with experience if you are willing to do what is necessary to succede.
Just keep on mind thoough, as your group grows and time goes by, the longer, harder, and more resource intensive the process will become if you do decided to update. You should start gradually making changes, and take baby steps if you are in a production, nothing that will hinder your development, but will clearly show your team that you guys are moving in a new direction as to getting stuff done. One of the stories our professor told us, who has had *a lot* of work experience in the SE industry for major compaines, govts, etc... is that if you look at this next slide:
The majority of all organizations are at Level 1, so that's the norm, BUT as you grow and if you want to do special work down the line for larger compaines or govt's, you will HAVE to be at least at a certain level, usually 3. If you are stuck at level 1, and all of a sudden need to get to 3, it takes a lot of money and time to get that done.
That's why if you are serious about thism and want your company to grow and do good, then you will need to tackle this problem ASAP and take advantage of the fact you guys are still small enough to properly get this started rather than wait until the end when you will have to have a certain level accompished.
Now to address a few points you bring up:
Oh really? All of the process models we have labored over and such did not seem to be suited for work that was 'close' nor 'far'. Those models are being used by some of the largest compaines in the world, and they are not all together to work, so perhaps you are misunderstanding them? Well granted you can't do something like an agile/extreme process of programming since peopel aren't located physically next to each other, but if you take a look at something like the Spiral model or the waterfall, none make really any mention to the fact of where people are, they just tell what order things need to be done. Even so, don't follow the norm, you can make your own!
Well first thing first, if you have never heard of Smoke Testing (also known as Regression Testing), then you should definitly take a look into incorperating that asap. All it means is that for any test you run starting at a build, you will always run that test for all future tests to make sure nothing has broke along the way. So for example if at build 4, you have some Test A, for all future builds, you will always run and verify Test A and make sure the results are the same. As soon as something doesn't match up, you know something went wrong. While this may seem like common sense, it is an official standard that you can say you use [wink] Just make sure eveyrthing is documented and tracked properly.
There's so much more that can be talked about, so I'd say try to do some looking for free online resources on Software Engineering (look for course notes, outlines, etc...) From there you can then get some more ideas of what you will want to do. Good luck!
Quote:Original post by olle hakansson
Heya, I'm looking for some experienced opinions on how to improve the software-engineering processes for a newly formed company.
Read over and learn the TSP and the PSP. That was the first thing that we had to do in our SE class this year, and after going though, myself being the project manager, it is very useful! If there's one thing that I learned from that class is that it's all about organization, communication, and standards, all of which you say your group lacks for the most part. Know that it's not easy to do, but it should come along with experience if you are willing to do what is necessary to succede.
Quote:So, why don't we just fix all the problems I've mentioned?
Just keep on mind thoough, as your group grows and time goes by, the longer, harder, and more resource intensive the process will become if you do decided to update. You should start gradually making changes, and take baby steps if you are in a production, nothing that will hinder your development, but will clearly show your team that you guys are moving in a new direction as to getting stuff done. One of the stories our professor told us, who has had *a lot* of work experience in the SE industry for major compaines, govts, etc... is that if you look at this next slide:
The majority of all organizations are at Level 1, so that's the norm, BUT as you grow and if you want to do special work down the line for larger compaines or govt's, you will HAVE to be at least at a certain level, usually 3. If you are stuck at level 1, and all of a sudden need to get to 3, it takes a lot of money and time to get that done.
That's why if you are serious about thism and want your company to grow and do good, then you will need to tackle this problem ASAP and take advantage of the fact you guys are still small enough to properly get this started rather than wait until the end when you will have to have a certain level accompished.
Now to address a few points you bring up:
Quote:process model (partly because we all work on a distance and many models don't take any consideration of that)
Oh really? All of the process models we have labored over and such did not seem to be suited for work that was 'close' nor 'far'. Those models are being used by some of the largest compaines in the world, and they are not all together to work, so perhaps you are misunderstanding them? Well granted you can't do something like an agile/extreme process of programming since peopel aren't located physically next to each other, but if you take a look at something like the Spiral model or the waterfall, none make really any mention to the fact of where people are, they just tell what order things need to be done. Even so, don't follow the norm, you can make your own!
Quote:no outspoken ways of testing code, etc..
Well first thing first, if you have never heard of Smoke Testing (also known as Regression Testing), then you should definitly take a look into incorperating that asap. All it means is that for any test you run starting at a build, you will always run that test for all future tests to make sure nothing has broke along the way. So for example if at build 4, you have some Test A, for all future builds, you will always run and verify Test A and make sure the results are the same. As soon as something doesn't match up, you know something went wrong. While this may seem like common sense, it is an official standard that you can say you use [wink] Just make sure eveyrthing is documented and tracked properly.
There's so much more that can be talked about, so I'd say try to do some looking for free online resources on Software Engineering (look for course notes, outlines, etc...) From there you can then get some more ideas of what you will want to do. Good luck!
Author
Thanks for the replies so far!
chollida1: CppUnit looks quite nice, I might just try that one if it fits our project.
Drew_Benton: Maybe I was unclear while writing my post, but I've also got theoretical knowledge of how to use SE for generic projects, and I was hoping to hear more about some actual field experience. Still, TSP looks promising, another thing to add to the list of things to check out.
chollida1: CppUnit looks quite nice, I might just try that one if it fits our project.
Drew_Benton: Maybe I was unclear while writing my post, but I've also got theoretical knowledge of how to use SE for generic projects, and I was hoping to hear more about some actual field experience. Still, TSP looks promising, another thing to add to the list of things to check out.
Quote:Original post by Drew_Benton
Read over and learn the TSP and the PSP. That was the first thing that we had to do in our SE class this year, and after going though, myself being the project manager, it is very useful! If there's one thing that I learned from that class is that it's all about organization, communication, and standards, all of which you say your group lacks for the most part. Know that it's not easy to do, but it should come along with experience if you are willing to do what is necessary to succede.
This is a mandatory course for all Software Engineers at the company I work for. The course is offered as a Graduate Level course taught by PhDs within the company. I found it pretty enlightening when I took it.
Quote:Original post by Drew_Benton
The majority of all organizations are at Level 1, so that's the norm, BUT as you grow and if you want to do special work down the line for larger compaines or govt's, you will HAVE to be at least at a certain level, usually 3. If you are stuck at level 1, and all of a sudden need to get to 3, it takes a lot of money and time to get that done.
We currently operate at Level 5 with an external review coming up in the next few months. (We really want to pass. It's very expensive and time consuming to go through the review process)
Quote:Original post by olle hakansson
Thanks for the replies so far!
chollida1: CppUnit looks quite nice, I might just try that one if it fits our project.
Drew_Benton: Maybe I was unclear while writing my post, but I've also got theoretical knowledge of how to use SE for generic projects, and I was hoping to hear more about some actual field experience. Still, TSP looks promising, another thing to add to the list of things to check out.
The great thing about what Drew_Brenton was talking about is that you are collecting extremely valuable information about your company's performance. You now have data that tells you how accurate your time estimates were (e.g. You thought it would take 4 days to code this module but instead it took 7).
You also have data about how many bugs were introduced at and at what stages in development they were introduced (e.g. 3 bugs in the Design Phase slipped through, 5 in Coding. Bugs introduced in the Design Phase took on average 2 weeks to fix, bugs introduced in Coding took 1 day to fix). You can draw the conclusion from this data that bugs introduced in the Design Phase cost more money to fix, then do a cost comparison to see how adding a Design Review phase to your process would help. Does it lower the number of bugs that make it through your Design Phase?)
Now your company has a leg to stand on when your customer (a publisher, or whatever) asks you to develop The Product, you can say with a great deal of certainty, "It will take this long." and you will have data to back up that claim.
I'd personally like to hear from established game companies on their use of Unit Tests, if any, and how their approach with it.
My one and only experience with Unit Tests was at a software dev house some number of years ago. The lead had this philosophy of always using Unit Tests for EVERY function we wrote. Granted, most of the functions were database accessors and manipulators, so it made sense to test them.
His reasoning is the same I've heard before : Fix a bug, write a test, and then test for that bug forever and always. If something goes wrong, it's easy to find. It's a very romantic idea indeed. But what ended up happening was our actual development time was about a third of the 'writing tests' time. For every function we wrote upwards of four to five test functions (testing against parameter limits, bogus data, etc). While this made our system quite stable, it took FOREVER to do and nearly killed our dev time. Add into that the requirement that we had to run the unit tests prior to checkin, which resulted in about 20-30 minutes worth of looking at tests run, and you have a few hours a day devoted to unit tests.
So I'm heavily biased against them (due to massive wasted time), and thus far have not seen them used in the industry, though I do not doubt some people employ them. Thus I re-iterate my question : For those that actually DO use unit tests, what is your process? How did you guys make it work?
.. hmm .. wonder if I should make this its own thread ... o.O
My one and only experience with Unit Tests was at a software dev house some number of years ago. The lead had this philosophy of always using Unit Tests for EVERY function we wrote. Granted, most of the functions were database accessors and manipulators, so it made sense to test them.
His reasoning is the same I've heard before : Fix a bug, write a test, and then test for that bug forever and always. If something goes wrong, it's easy to find. It's a very romantic idea indeed. But what ended up happening was our actual development time was about a third of the 'writing tests' time. For every function we wrote upwards of four to five test functions (testing against parameter limits, bogus data, etc). While this made our system quite stable, it took FOREVER to do and nearly killed our dev time. Add into that the requirement that we had to run the unit tests prior to checkin, which resulted in about 20-30 minutes worth of looking at tests run, and you have a few hours a day devoted to unit tests.
So I'm heavily biased against them (due to massive wasted time), and thus far have not seen them used in the industry, though I do not doubt some people employ them. Thus I re-iterate my question : For those that actually DO use unit tests, what is your process? How did you guys make it work?
.. hmm .. wonder if I should make this its own thread ... o.O
Quote:Original post by Drew_Benton
/Disclaimer: Just finised up a SE class in college, so I'm far from a professional or expereinced in the real world sense [wink]Quote:Original post by olle hakansson
Heya, I'm looking for some experienced opinions on how to improve the software-engineering processes for a newly formed company.
Read over and learn the TSP and the PSP. That was the first thing that we had to do in our SE class this year, and after going though, myself being the project manager, it is very useful! If there's one thing that I learned from that class is that it's all about organization, communication, and standards, all of which you say your group lacks for the most part. Know that it's not easy to do, but it should come along with experience if you are willing to do what is necessary to succede.
Processes aren't appropriate for his organisation. It's too small and loose to start putting in beurocracy. Those strategies are for 100+ people projects (imo/ime). You need to balance the immediate benefits with the long term benefits. If you focus on the short term, you will have a mess in the future. If you focus on the long term, you won't make money despite your wonderful infrastructure -you'll not have a product! So, an organisation needs to balance it.
In the beginning, you obviously need to have a lot more focus on the short term. In fact, you likely want no time spent on the long term. You need to get to sustainability.
Now, getting more theory to the metal: unit tests give immediate feedback and are therefore immediately useful. They should be written before the actual code unless you're doing some exploratory programming. Not only do unit tests give immediate feedback on some common bugs, but they can help you define an interface. If you have trouble writing a test for something it gives a clue that your module isn't well defined and you can refactor the design until you have some tidy tests.
[Edited by - flangazor on December 4, 2005 7:39:54 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
