Designing software at complex levels?

Question

Hi,

I'm writing a software that appears to be quite a lot more complex than I realized earlier. It performs several sub-tasks, has a set of entirely different tasks and integrates itself to other applications, modules and programming languages. There are hundreds of todo's I need to do, and everything seems a bit too complex to think straight forward. What are some good ways to design your software other than "just writing"? I need to organize my project somehow, I need to know what to write without spending one hour first for figuring out what to do next.

Has anyone been in a similar situation?

Answer 1

Break down your project in small tasks (less than a day of work). Organize them by groups. Prioritize them (maybe you need to do feature X in order to do Y). Start coding!

---

Any project, as complex as it can be, is just a succession of smaller tasks. Once you realize that, it's easier to focus and find a way to approach the project. Of course breaking down everything into small tasks is work and not trivial. If you don't have experience in this, try getting help from colleagues. But the best way to get experience is to try!

Depending on your situation and personnal preferences, you could consider using an agile methodology such as Scrum or Kanban. You should also use a project management tool in order to keep track of what you have to do. It can be anything from post its to pivotal tracker, just find the one that's right for you.

Answer 2

Try using SCRUM & TDD.

Plan short iterations (1-2 weeks) with clear, short goals, try to create some end-to-end scenario as soon as possible and only create the required infrastructure.

Use TDD - I found that it helps when there facing unclear goals - by writing the test before you code you focus yourself on the objective one feature at a time.

Answer 3

Looks like you need to organize your software in several functions instead of handling it as a single spaghetti plate of code.

You may want to use some formalism to structure your thinking, such as UML for static architecture or MSC for dynamic architecture.

Answer 4

I have only been in similar situations of a much smaller scale. However, I hope these hints may help.

• have a design session (preferably with colleagues) to figure out the rough architecture for your software
• try to break down complex stories into smaller subtasks which are manageable one by one
• write unit tests - these will enable you to boldly refactor your code without the fear of breaking something, if you feel that your existing design is not quite right

Answer 5

I'd imagine most developers have come across that "oh sh**" moment when you realise the full scope of what you've been asked to do :)

It sounds like you're working as a one-man team so here are my tips:

1. Talk to the client - Can't stress this enough. You need to have an open and honest conversation now. If they've asked for the moon on a stick and you're being paid tuppence, nobody will get the right result from this endeavour.

2. Break the system down into high-level features (e.g. application will export X to system Y), work with the client to identify sensible vertical slices that can be implemented incrementally and prioritise them

3. Within the features organise and prioritise sub-tasks

4. As marcgg suggests, try and break the tasks down into manageable chunks, I usually use 4 days as a maximum, any more than this and you don't understand the detail enough to estimate accurately so refine it further. However it is not always necessary to estimate everything to granular detail. It's ok to agree to refine things later so long as both you and the client understand where the possible time slips may occur.

5. Get a decent task tracking tool like JIRA or whatever. You want to offload task juggling from your brain so you have the capacity to tihk about implementing the solutions.

6. Remember that shipping is a feature - don't disappear into a hole coding like crazy for six months. Keep delivering prototypes (or much better proper working versions with a growing subset of the features) regularly and work with the client not just for the client.