I'm junior programmer and I would like to know how professionals write their code or which steps they follow when they are creating new software. I mean, which steps they follow, which programming methodology, software architecture design application software, etc.

Which steps I have to follow from The Idea I have in my mind to the final version of the application in any language. Or perhaps how is your programming steps or rules that you used to follow.

Because every time I want to create the an application I spend few time on the design and a lot of time coding (I know, that's not good).

  • 5
    There are a lot of development method(ologie)s used in the field, and there is no One Right Way to do it, since the field is so diverse and circumstances can be wildly different. Narrowing your question to some area(s) / application type(s) / programming language(s) would help you get meaningful answers. Jul 25, 2011 at 12:16

4 Answers 4


I would recommend reading a few books to get started.

A general book about the art, craft, and engineering behind software development is The Pragmatic Programmer: From Journeyman to Master. This book talks about everything from dealing with people to tool support for your development. It covers a lot of ground in a very small package, and I even reread this book from time to time. The advice is applicable to everyone in software development, from the programmer through the project manager.

Rapid Development: Taming Wild Software Schedules. It's the book used in the process and project management course that I took, and it covers a number of major process models and methodologies, when they apply, and commonly accepted best practices for managing projects. However, like most work, it focuses on team projects as opposed to individuals.

On the coding side, Code Complete: A Practical Handbook of Software Construction is a recommended read. It focuses on how to write good, clean code, with concepts that apply to a number of languages. The emphasis is on procedural and object-oriented programming, but the advice can be applied to any language or paradigm.

For designing object-oriented software, the classic texts include Design Patterns: Elements of Reusable Object-Oriented Software and Refactoring: Improving the Design of Existing Code. There are a number of books and resources in this field, and a lot of design decisions are driven by the technologies you are using and the requirements of your project. For software system architecture, a classic text is Software Architecture in Practice which discusses topics ranging from architectural views to product line development. That was the book used in my software architectures course, but some professors were using Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives in its place.

However, you can't just read these books. The important thing is to apply what you have read to your projects at work, school, and at home. You can read all you want, but if you don't apply your knowledge, it's meaningless.

On my projects, a lot of what I do is driven by my goals, either in terms of personal development or the requirements of the project. You aren't going to find a one-size-fits-all methodology or process, so the best bet is to look at commonly used best practices, find out what works for you and your team, and learn from mistakes for future projects.

  • Thank you very much @Thomas Owens I really appreciate your help :D
    – IkerB
    Jul 25, 2011 at 12:47
  • @IkerB If you find an answer good, you should upvote it. If you find an answer that best answers all of your questions, you should accept it by clicking the checkmark next to it.
    – Thomas Owens
    Jul 25, 2011 at 12:49
  • 1
    +1 because your booklist looks suspiciously like the stack of reference I have on my desk right now. Jul 25, 2011 at 13:10
  • @MadKeithV With the exception of Refactoring, they are were all required reading when I was getting my degree in SE. Refactoring was pointed out as a good book to read in at least one course, though. All of them are sitting on my bookshelf at home, most having been opened recently. I just can't bring myself to bring them to the office, since I might want them when I'm working on something at home.
    – Thomas Owens
    Jul 25, 2011 at 13:13
  • 1
    @Thomas Owens - you are correct, it is in mine as well. The very first words of the preface are "This book isn't an introduction to object-oriented technology or design.". Jul 25, 2011 at 13:30

What I do is to look if a similar project has already be done. It doesn't need to be exactly the same, but something related to my new project.

I reverse engineer the java code into a model and extract UML diagrams to visualize the code. I try to understand how it works and the logic. Once I understand then I redesign what I need and generate again a new java code.

There is no copyright on the code I get because I don't copy the original code of an other project. I only look at the skeleton and generate code from the model. The generated code is therefore clean with no copyright. It does usually over 80% of the skeleton of the first draft design. I don't think this is a nasty behavior saving time doing that !! I can not only reverse .java but also .class code. Or even mix them if more than one project. I immediately get the big picture of the project and can copy what I need.

Finally I put my personal code into this generated code in order to customize it. I think that using an already stable project is a key factor in order to have a good architecture. I am not a genius but it works really well and save me plenty of time. I have realised that because I used an already project, they have usually done an extendable architecture which is really important if you need to evolve your project. If I did have created a structure for only the first requirements I got then I would have been stuck later.

  • Thanks UML_GURU!! Your answer is really interesting and productive :) I was just wondering how can generate the UML diagram from an Android APK file. I guess that first you have to decompile the DEX file to gererate the *.class files and afterwards decompile those files to generate the original Java source code. But once you obtain the java code how can you generate the UML code. There's any script application that can make the whole process of decompiling? Thanks in advance
    – IkerB
    Jul 28, 2011 at 19:25
  • I only use JDT based on Java but not Android which is using another kind of JDT. I think you need to google in order to find a tool. Good luck for your project
    – UML_GURU
    Jul 29, 2011 at 20:45

This is a very broad question and I must first say that every company/developer have different methodologies and design processes. So I will only speak for my own personal experience.

The first step is to ask yourself what all the specifications are. Not only do you have to think about the end product, but also about the process and the life of your application after deployment. Are other programmers working on it? If so, you (and your team) might want to develop the entire framework first so each of you can be working simultaneously on different aspects of the application. Is the application going to be extended in the future? If so, you'll need to ensure that you provide a high enough level of abstraction (proper OOP hierarchy, etc) to enable that. Are there going to be 3rd party developers working on extending your application (via plugins, etc)? If so, you must make sure your application is safe and your users are properly protected (making sure your variables/classes are given the appropriate access modifers).

I assume that the actual application specifications are already laid out clearly. If not, you must do that ASAP. There's nothing worse than having a changing specification while developing a large application. Now while you program, you should keep all these ideas in mind (after all, what's the point in figuring all these questions out if you're not going to pay attention).

Next on the list is choosing your technologies and frameworks (if you're using one at all). You don't want to be stuck with doing a large project from scratch. Do a lot of research on the pros and cons of each and evaluate accordingly. Choosing the right framework can mean the difference between a 10 hour long project and a 100 hour long one.

Google is your best friend. If something subtask requires a significant amount of time to code, look it up. I have saved countless hours just by typing in a simple search query and copying+pasting code. Don't plagiarize though, that's bad ;) But don't blindly use other people's code either. Just because it's publicly on the web doesn't mean it's the most efficient piece of code, or the most safe piece of code. Always carefully review what you find.

Now finally when you can't use and reuse every last piece of code you can, then write your own. Make it clean, concise, and efficient. Satisfy all your requirements while making it the best piece of code you can possibly think of. No one likes reading ugly/inefficient code.

Perhaps this is my own pet peeve (though I'm sure it bothers many others), but please format your code nicely and consistently. Coding can be an art, do me a favor and don't make it look like you typed it up with your hands tied behind your back.

  • Thank you very much @tskuzzy, very useful advice that I'll keep it in mind every time I make an application :) Thanks
    – IkerB
    Jul 25, 2011 at 12:25

Some of the methodologies I've seen used a lot:

  • Code & Fix. You code something. If it doesn't work, you change something. You keep doing this until it works well enough to fool management that it's done. This is "Agile" development at its worst: "what is the minimal amount of work I can get away with?". Needless to say I'm not a fan of this methodology - but you may recognize it from your colleagues or yourself on a bad day! It's very hard to get any productive work done if you don't already know exactly what you are aiming for in the end result.

  • Throwaway prototyping. You start by getting your feet wet using the code & fix mentality, with one extremely important difference. From day 0 you know that you will throw away this code & fix prototype once you know enough to do it "right" or at least a lot better than the first time. This is a very useful methodology for very new technologies, algorithms and unknown problems. The biggest difficulty is to have the self-discipline to actually throw away the prototype and start from zero. You might think this method takes twice as long, but it really does not: once you know how to do something you need less time to do it. You still need to know somewhat what you are aiming for, but you can try a few different prototypes just to pin down exactly what works best.

  • Big Design Up Front. If you do projects for the army, the government, NASA, the medical field, or organizations in love with CMMI L5, you will recognize this. Everything is specified in minute detail in documents and specifications before any production code is written. This works well if you can get everything right from day 0 and no requirements change. In almost all cases something will change though, so you may find a lot of the big design effort was premature. If you have document for regulatory purposes then obviously you have to, but there are always ways to have "just enough" design and documentation before you start actual coding. Upside: at all times you are able to know exactly what your end goal is, if you can still find it in the piles of paperwork.

  • Just enough design up front - my most often used method. A lot of the things I do aren't novel enough to require throwaway prototyping, but I don't want to get stuck in Big Design Up Front and waste a lot of effort, nor do I want to code & fix my way through the day and end up with a cobbled-together "design" that I actually hate. So I take the usually underspecified requirements, and work out some designs on paper, or in some kind of design tool (can be UML diagrams in Enterprise Architect, or just drawings in Paint Shop Pro). I discuss these with the people responsible for the requirements until I get the feeling that I know what they need. Do not focus on what the customer asks, and not even necessarily what they want, figure out what they need and how you can best provide it. Then you write your first version in code - not quite a throwaway prototype (if you are on the money, you'll want to continue working on it), but not polished to total perfection either (because you might still be wrong). Present your version, and poll the reaction of your customer. Either continue polishing, or try another avenue if it's not really going where it needs to.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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