9

I'm in a new job where the project needs to meet strict quality standards, be heavily documented, managed in great detail, UML diagrams, and all those things that are opposite of "cowboy coding" where most of my past work experience has been. Think of the way large-scale aerospace or medical device software is developed.

I'm glad to leave the chaos of cowboy coding and am curious to see how well heavyweight engineering methods go. But how can one rapidly gain experience with the heavy methods?

Besides simply being in the job for some number of months/years, that is.

With a mere language, or new API, one can hack up a toy test program, read, deliberately make mistakes to see what happens, etc. Like becoming good at bicycle riding or playing a musical instrument, practice is essential. It is easy to pick up a flute and spend half an hour every day; no need to join an orchestra or be a full-time flute consultant. But how to practice software engineering activities that are large, complex, involve teams, and much of which is all about communicating and planning, and avoiding miscommunications and exceeding schedule and budget limits?

This doesn't seem possible to do solo. Is there a way a small number of people could simulate engineering a whole big project on a small scale in a short time (one day)?

Improve this question
0

3 Answers 3

Reset to default
1

Is there a way a small number of people could simulate engineering a whole big project on a small scale in a short time (one day)?

Yes, this is possible to some degree. About 10 years ago I took part in a workshop at the OOP conference in Munich where 16 people were given the task of making a rough analysis and design for a small business software. The first half of the day was mainly about finding a team structure for solving the task with 16 people, and the second half of the day focused on solving the task with this team.

During the first part we were guided to split the 16 people into groups of four. Each four person-team had to work out suggestions for the team structure (under time pressure), afterwards a shoot-out process was applied to make a decision which team structure might be the best and should be used for the second part of the workshop.

Unfortunately, whilst the first part, we made the mistake to try to give each one of the 16 people a job within the intended team structure. That mistake lead to chaos in the second half - because 16 people are way too much to solve such a task. A working solution might have been to split up the 16 people again to smaller teams, or choose 3 or 4 people to do the main work, but in the heat of the moment we missed to see this.

I am still under the impression that I learned a lot about typical problems one may face in bigger project organizations that day. I don't know where you can visit such kind of workshop somewhere near to you, or who offers such a thing nowadays, but if you have a chance, I would highly recommend to attend it.

Improve this answer
2

Start with a checklist. (You knew that was the first step, right?)
Make sure the checklist lists all of the standard documentation for your current project. ie. UML Diagram, functional spec, high-level and low-level designs, etc... The systems engineer in me will suggest using an RTVM (requirements traceability verification matrix)

Pick a sample program to work on. If you can't come up with one, google "code katas" or check out Google's codejam archive of challenges. Or just build a calculator. :-)

Build the functional spec for your sample program. Then move into the high-level design, UML diagram, etc... Build it to spec. Test it. Every time you find a significant flaw in your spec (as defined by your current work practices), then you need to step back to that stage of the SDLC and revise before moving forward again.

For your first round, go ahead and keep it small. Cycling through the process is more important than overkill within any particular stage. For subsequent rounds, add in the features that you left off. Tracing, logging, performance analysis, test-scaffold, etc.. What you'll want to add will depend upon what your employer expects for your real work.

After you have iterated through the design / build / test / repeat cycle several times, you'll have built up skill and experience in the "heavyweight" components that are worrying you now. The iterations will also show you the interconnection between the various stages and the documentation generated. The valuable lesson there is showing how a 5 minute code change can have a multi-hour ripple effect elsewhere due to doc updates and testing requirements.

Improve this answer
1
  • 1
    @gnat - props for the link on the checklist. Good addition. Commented May 15, 2012 at 14:41
-1

Experience with "heavyweight" practices only comes from doing the real thing. There's no way to effectively practice it in isolation. You can, however, study it. There are many case studies and sources you can study and ponder.

Not all the practices you see or study are necessarily positive, however. Software development is a fluid thing, and what seems hardcore and strict today may seem silly and redundant tomorrow. This happens both through new tools and experimental experience bubbling up from startups to the more conservative organizations.

Basically, change and risk management seems to have a unique shape for each organization. Your best bet is to keep an open mind, but don't carry too many assumptions from team to team.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.