

Question: Do any of you use a software engineering "process"? - mynameishere

I've been involved in different kinds of software processes, and the most effective for small projects seems to be:<p>1. Talk generally about what we want to achieve.<p>2. Mock up some screens.<p>3. Agree on relevant technologies (language, platform, data store).<p>4. Assign responsibilities.<p>5. Commence.<p>
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).<p>Can any of you small-company types describe your process, if any? What is most effective for you?
======
epi0Bauqu
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.

------
mmaunder
I use the Nike process: JUST DO IT!

------
axcesspoints
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.

------
bcater
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."

------
palish
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.

~~~
edgeztv
What kind of application takes 15 minutes to fully build? (I'm genuinely
curious - not sarcasm).

~~~
palish
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 :)

------
lkozma
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.

