Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What to do people do develop a design for a s/w for a given set of requirements?

I like many people joined a Semiconductor MNC and got stuck in maintenance for quite a couple of years. My work was usually changing a lines of code for windows drivers supplied by my company or a couple of small script (style like) C programs for validating h/w. As a result I developed the bad habit of 'programming by coincidence'. I have not developed the ability for designing tools/programs from scratch. I was the only s/w member of the local team and thus some grunt work from the well established other site of the company came to be done by me.

Now I have moved to a different company and thus finding developing from scratch very difficult. How do I unlearn my bad habit and develop this ability of designing s/w and then coding it ?

share|improve this question

closed as off topic by MichaelT, Bart van Ingen Schenau, gnat, Martijn Pieters, Walter May 6 '13 at 11:50

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Keep in mind that design is a skill. You get better at it with practice, and it can atrophy if the skill isn't used. Don't sweat it too much if at first you have a hard time. –  Michael K Jun 23 '11 at 18:18

3 Answers 3

As I said on previous occasions, writing software is craftsmanship. When you watch a good craftsman, you can learn a lot of the principles that apply here, too.

When you have to write a piece of software from scratch, the first thing to do is a good understanding of the desired solution. This starts with collecting requirements. The initial collection doesn't have to be complete (that's one advantage of writing software, you can change things later, in difference to crafts that deal with physical materials), but the more you can get, the better.

Then order these requirements on whatever structure seems the most appropriate. One good approach is to write user stories. Each story describes, from the perspective of a user (this can be a person or another piece of software) what your software needs to do when certain input and stimulation (e.g. key presses or mouse events) are provided. Now group your user stories.

Eventually a clearer picture will emerge as to what this piece of software needs to look like.

Once you have a fair collection of these stories (e.g. 2-3 months worth of work, but this can vary a lot), pick a few related ones, which are relatively simple to implement, and start writing code. Write unit tests for your code, where each test covers a particular aspect of that story. These tests must cover the expected outcome as well as any error handling. Refactor your code after each unit test, to ensure it is as clean as possible (read this book about clean code and this book about refactoring). Then move on to the next story.

There will be times when you need to do some major refactoring, because the structures and designs chosen initially are not adequate any longer. Don't be afraid of this, the unit tests will help you to make sure that all your requirements are still met.

Over time, architecture will emerge. As you get better (with lots of practice) you will learn to avoid some common pits from the start and you will get faster. While you carry on implementing user stories, also carry on collecting new ones. Always keep the list of stories prioritized (ask the users what are the most important stories to implement next). When writing user stories, just put enough detail in the story to understand what it is about. The fine detail should be decided at the very last moment, i.e. at the point of implementation. Make sure you have access to the users to ask them questions.

Soon you will come to realize that there are certain things that you need again and again. These are called patterns. There are numerous books on software patterns available. The two best ones I have read (and I haven't read all of them) are the original GoF book and this one. Good luck.

share|improve this answer

I went through a similar process internally at my job, it can be overwheling. What helped me was to realize that you're not really starting from scratch. Your company probably has set ways of doing things, structures that are reused, and some software with a similar features. When you are starting out you can lean heavily on these and steal code and ideas, you will also steal all the problems in that design / code, but as a programmer used to maintenance this is something you are used to and you probably have strong debugging skills.

The other hard part is dealing with a greatly increased scope, you are used to programming in small predefined chunks and you need to break your new development down into similar sized chunks, preferrably ending up with something small that you can test.

It gets easier as you go. You'll get stuck, when you do, try to break the task down into even smaller peices. Good luck!

share|improve this answer

My first few jobs as a software engineer involved primarily new design. However, my last and current jobs deployed me in a maintenance role. My situation is the converse of yours, but I can think of some ideas for you to apply:

  1. Prototyping. While you may feel that new development is difficult, you have stated that you are given a set of requirements. Begin by writing code to fulfill the requirements, even if it is horribly ugly code. As good writing comes from many iterations of refinement so does programming. Get something, anything, coded up.

  2. Maintenance of software is maintaining order in the system. This is something that begins as soon as code is checked in. Once you have coded your first prototype, either store it away and start over (i.e. throwaway prototype) or "maintain" your prototype by fixing bugs and refactoring parts of it that are ugly (i.e. evolutionary prototype). Fix bugs and refactor your code or its underlying ideas.

  3. If either your requirements are not fulfilled or your code does not work (or is too ugly to pass code review), repeat #1 or #2 as appropriate. Iterate until you are satisfied.

This may seem to be a cop out answer, but it shouldn't be. The hardest part is getting started, so temporarily suppress your design inhibitions while you prototype. (I recommend that your prototype iteration be throwaway, but save bits and pieces that could be useful for the next iteration. You may find evolutionary prototyping more effective, due to your background in maintenance.) Michael Feathers calls a similar approach "scratch refactoring" in his book Working Effectively with Legacy Code

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.