Question: Do any of you use a software engineering "process"?
6 comments
The approach that works best for me is to just start building it :).
In all seriousness though, this is truly the case. I surmise that most of us already have a platform of choice. I know I do. So once that is taken care of, just go ahead and start.
In terms of how do you start, I think it is most effective to work on the critical functionality path. Just do everything that is absolutely critical to make it functional.
In terms of where do you start along the critical functionality path, I approach it from the user perspective. First I need the login screen or whatever. OK, I need to build the ability to login. Then the next thing the user is going to want to do is X, so I need to make X work.
With this process you get from nothing to something functional in little time, and then you can just build from there. I have been on projects where we talk it through first, and even spec, but in my experience this is a waste of time for small projects at all but the highest level. Almost immediately when you start building it you notice things you didn't in the talking stage.
I'm interested in what other people do, but this has always worked for me. Of course, I like to work alone :). But it has worked with other people too. You just break up critical functional tasks the way they naturally break up.
In all seriousness though, this is truly the case. I surmise that most of us already have a platform of choice. I know I do. So once that is taken care of, just go ahead and start.
In terms of how do you start, I think it is most effective to work on the critical functionality path. Just do everything that is absolutely critical to make it functional.
In terms of where do you start along the critical functionality path, I approach it from the user perspective. First I need the login screen or whatever. OK, I need to build the ability to login. Then the next thing the user is going to want to do is X, so I need to make X work.
With this process you get from nothing to something functional in little time, and then you can just build from there. I have been on projects where we talk it through first, and even spec, but in my experience this is a waste of time for small projects at all but the highest level. Almost immediately when you start building it you notice things you didn't in the talking stage.
I'm interested in what other people do, but this has always worked for me. Of course, I like to work alone :). But it has worked with other people too. You just break up critical functional tasks the way they naturally break up.
I use the Nike process: JUST DO IT!
We've just launched a consumer oriented website. We started by identifying the key features that were necessary to get to monetization. Then the whole thing was mocked up in Powerpoint with EVERY hyperlink included. From there we developed functional specs for the site. At this point it went off to the developers and we continued to work on the details - which photos, what text to include in which emails etc. We put together an excel spread sheet for QA that allowed us to test and track the bugs. As things changed, we updated the specs so we would have good documentation about what has been modified. Documentation is important because down the road when this becomes a big company, it will be easier for new developers coming in to get up to speed. I'll confess though, that some of our documentation is emails.. which are stored with the requirement docs.
I once worked on a small software project with two other people, and because the requirements and restrictions were so rigid, we didn't have to do much more than work out a UI - the system itself was pretty straightforward to implement. Thus, we figured out what each of us had done before or had a good working knowledge of and started coding.
Currently, I'm working on a much larger project with one other person. Our strategy so far is to try something, figure out why it didn't work, and then try something different. It reminds me of what one of my former math teachers told me: "Whatever you do, don't just stare at the problem. Do something, even if you know it's wrong."
Currently, I'm working on a much larger project with one other person. Our strategy so far is to try something, figure out why it didn't work, and then try something different. It reminds me of what one of my former math teachers told me: "Whatever you do, don't just stare at the problem. Do something, even if you know it's wrong."
At work, it takes 15 minutes to fully build the application. If the system I'm building is sufficiently small, I go ahead and code it right away and simplify as it's built.
If the system is large (for example, I'm currently building something which is around 1000+ lines) I write a functional spec first, figuring out the high level design and a few nitty-gritty lower level things. This helps simplify things because you can see exactly how two pieces that look similar can be split off into one piece.
If the system is large (for example, I'm currently building something which is around 1000+ lines) I write a functional spec first, figuring out the high level design and a few nitty-gritty lower level things. This helps simplify things because you can see exactly how two pieces that look similar can be split off into one piece.
What kind of application takes 15 minutes to fully build? (I'm genuinely curious - not sarcasm).
A massively multiplayer online game platform. It's about 5 years in the making, so it's racked up a lot of code. www.heroengine.net and www.play.net/hj have more information if you're interested :)
Some random stuff that works for me:
1. refactor often 2. avoid code duplication 3. test everything 4. even if you hate docs, it's good to have some written specs, or even better, some initial tests.
1. refactor often 2. avoid code duplication 3. test everything 4. even if you hate docs, it's good to have some written specs, or even better, some initial tests.
1. Talk generally about what we want to achieve.
2. Mock up some screens.
3. Agree on relevant technologies (language, platform, data store).
4. Assign responsibilities.
5. Commence.
Needless to say, this is not your typical "big company" software process. I've also been involved in more complicated processes that would involve multi-month-long documentation orgies, in which 50-150 page requirements and design documents would be made, remade, and remade (often for code that would total less than a thousand lines, and that was conceptially just a CRUD app).
Can any of you small-company types describe your process, if any? What is most effective for you?