What's the best approach to studying Open Source projects or any large codebase?

There is a Open Source project which I need to use in my project. All other functionality is built on top of it. I am new to programming and find it very daunting. There are a lot of Open Source projects and APIs out there. At one point or another we need to use these in our projects since we don't want to re-invent it again. There are tons of lines of code written in those Open Source projects by other programmers. It's really hard to understand. How do I pick a library or API and understand it quickly to use it in my project? Do I need to understand each line of code, or just have a general overview of how it works? Please share your experience of how you approach it and any guidance on how to look at it.


Developing my momentum on open source projects

I've been struggling to develop momentum contributing to open source projects. I have in the past tried with gcc and contributed a fix to libstdc++ but it was a once off and even though I spent months in my spare time on the dev mailing list and reading through things I just never seemed to develop any momentum with the code. Eventually I unsubscribed and got my free time back and uncluttered my mailbox. Like a lot of people I have some little open source defunct projects lying around on the net, but they're not large and I'm the only contributor. At the moment I'm more interested in contributing to a large open source project and want to know how people got started because I find it difficult while working full time to develop any momentum with the code base. Other more regular contributors, who are on the project full-time, are able to make changes at will and as result enter that positive feedback cycle where they understand the code and also know where it's heading. It makes the barrier to entry higher for those that come along later. My questions are to people who actively contribute to large opensource projects, like the Linux kernel, or gcc or clang/llvm or anything else with say a developer head count of more than 10.   * How did you get started? Was there a large chunk of time in your life that you just could dedicate to working on the project? I know in Linus's case he had a chunk of time (6 months) to get it started.   * What barriers to entry did you encounter?   * Can you describe the initial stages of the time spent with the project, from when you had little understanding of the code to when you understood enough to commit regularly. Thanks


Persuading management that refactoring code is a good idea

> **Possible Duplicate:**   >  Best supporting argument for refactoring Has anyone got any tips for persuading management that refactoring code is a good idea ? I was asked something like > "After this refactoring, will I have a better product ? How does time spent > on this benefit the company?" Or something along those lines. I can see why management asked it but my response was not fantastic. I said something about how a well designed piece of software will mean that adding new features in the future will be quicker and easier. Does anyone else have any tips ? Many thanks.


How to handle a client that wants me to use code from Google under all circumstances?

I have a client that has been upset with the fact that it takes more time than he thinks to complete a feature / bug in a web application. He is more of a project manager that has hired me as a sub-contractor. He has constantly been questioning the estimates I have given him, and is always trying to get me to agree to do things in a less amount of time than I have estimated. I have made it clear to him that I will not always bill for the full estimate if it does not in fact take me that long to complete. He also told me that if there is code on google (w3schools), that I should use that and not write it myself. I have been doing business with this person for 12 months. Just to clarify what I mean by "Google", I mean that he would always prefer I copy / paste code that I have found from Google rather than writing code myself.


How do you dive into a big ball of mud?

> **Possible Duplicate:**   >  How do you dive into large code bases? So there is a question about understanding code. Mine is a similar problem. It started when I joined my current org. and like I always do at beginning I tried to get a feel of the code starting from high up and working my way down to details. Only, there is no detail, or to be more precise I have not been able to discern any design to the this big ball of mudness. Application is riddled with duplicate/unnecessary data, there is no attempt at encapsulation or abstraction or hierarchy with same code copied in multiple classes/modules for the same functionality (of course this means that the duplicated code is out of sync everywhere). Majority of the code concerns the manipulation of POD style classes entirely obscuring business logic in between, DAOs are horribly mutated.To illustrate following is a typical statement in the code               W.X[Y].Z = A.B.C[D]      To summarize the code is to OO programming, sorry make it any programming, what Freddy was/is to teens at Elm street. Now I would like to gradually refactor this insanity away, but I for that I must somehow get a hook on the code. So my question is, does anyone know of any systematic approach to this situation , or do I have to hack till I get the job done. Update: Just to add some additional information.   1. Ours is a new team so we can't talk to anyone who is familiar.   2. I have switched to a new domain as a result I am not familiar with it.   3. We don't have any direct interaction with the customer.


Engineering a better solution, coming from existing codebase

**The Code** I have high-business-value daily-used-by-customer software that is written in PHP and spans approximately 600K lines of code. Customer for a long time needs, wants, and demands new features and functionality. The time to have it done is _yesterday_. So, just write the new features and implement new functionality and deliver it to the customer, yes? Well, no, here are some problems that have been causing considerable pain to current developers: **Existing code-base is ... abig ball of mud.** Notable problems:   * code is hairy - a single feature permeates everything, tracing code is a pain, and adding a feature may potentially impact everything else   * there are no tests   * mix of procedural and object oriented code ridden in bad programming practices   * files reaching 6000-lines of HTML, CSS, PHP, SQL, jQuery, JavaScript, comments   * complete disregard/non-existence of MVC/separation-of-concerns pattern. Code is intermixed together   * some business logic depends on volatile things that have no relation to the code (like database metadata)   * hardcoded values, paths, and lack of configurability contribute to lack of security of current architecture   * large repeated blocks of essentially the same code contribute to similar features working slightly differently. Updating one does not update the other   * code is slow, lack of documentation., etc, etc. quite a few other things can be done better **It works...** The good thing is that it works... The functionality that's there, is reasonably worked-out for actual business cases, but ... going forwards is painful. **The Problem** It is easier now (and faster) to add a new feature using existing code style, mostly using cut-n-paste-n-modify approach, thus perpetuating the badness, than it is to do rewrites of this thing using currently existing modern best practices. **Solution?** There is a talk about rewriting the whole thing using one of the currently- leading frameworks (i.e. ZF2), but in doing so it means ignoring customer demands, taking a long time to build the software, and essentially creating new software (version 0.0.1) for the customer, with all the new-software bugs and lack of mature-software feel and functionality. Another thought is to do some incremental development. i.e. When a new feature comes about, write it using a new approach. This is currently failing for the reason stated under "The Problem" title above. Yet another idea is to do some slow refactoring of existing codebase... It might work in cleaning up things like MVC and a host of other things, and it will take a long time, and it will essentially feel like unraveling a messed up tightly-wound knotted ball of yarn. But doing this will not address things like unit testing, dependency injection, modern framework principles, and so on. So, in the end, new features are coming, code is being added, and the existing codebase is not getting any better. What might you suggest to do in this case?


What to do when tackling an unfamiliar Code base?

> **Possible Duplicate:**   >  How do you dive into large code bases? When you join a pre-existing project that has a large code base, what are some of the things you do to get acclimatized quickly towards being able to code soundly in it? How much time do you spend reading, making diagrams etc as opposed to diving right in and coding?


How should I go about learning a very large and complex application?

Being a young and fairly inexperienced developer recently employed by a "real" software company I'd like some opinions and pointers on how to do the following: **Approaches on how to get familiar with a companies products , especially when you've no idea how it all works**. The company I'm at now has one HUGE product , continually evolving and having been here for 2 weeks I've still no idea how it all sticks together apart from a special kind of glue made from the tears and frustration of young developers, it's incredibly fragmented and only 4 people in the office know the inner workings, all of them constantly busy **Give useful input on the product :** Now, I know I'm just a kid in the company and I can't be expected to deliver anything ground-breaking in my first months, but you have to give as much as you're paid. I'm getting around twice as much as at my previous job but objectively speaking I've not done anything to deserve it yet. Just sat around staring at my laptop screen trying to decipher code. Now you might say that this is what I'm here for , to start off with at least, but at my previous job I was something of a go-to-guy, making decisions and contributing to almost every aspect of the company's daily running. While that was a lot of work I enjoyed the feeling of being 'connected' in the inner workings of the company I have a stake in (a symbiotic relationship if you will). _please edit this point down, I'll leave it up to you guys to decide what's important_ _I'll post more things as I think of them, have to get back to reading and writing something only vaguely resembling C#_


What kind of process should I use to learn a big system?

> **Possible Duplicate:**   >  How do you dive into large code bases? I just joined a new company and started to study one of the their bigger system. For me to be productive, I need to understand the entire system without too much help. Other programers are really busy and dont' have time to hold my hands. I used to use brain map to draw a pictorial representation of the system. Any recommendations on what is the right appproach to dissect a big program? It is a .net prgoram by the way.


How to estimate the length of a programming task

What process do you use to estimate how long a (significant) programming task will take. Do you use one or more of the following:   * intuition/guessing   * reference to similar tasks whose estimated/actual lengths you recorded   * reference to the lengths of similar task others recorded   * saying it will take the length of time allocated for it (by your manager)


How to properly take over a complex PHP project

I've been tasked to correct some issues on the backend of a large website project that has been outsourced for some time. The original developers and us are not on good terms so it's not feasible to get them involved. The technology stack is as follows:   * MySQL 5.x   * PHP 5.3 (and a variety of supporting libraries)   * Apache with mod_rewrite The problems I am facing are:   * No documentation, not even comments   * 4 index files in root, plus 2 main files in a combo of php and html and 1 default.php, the referenced index file in .htaccess references their local test server.    * Duplicate file names / files   * Atrocious file system layout ( ultiple js folders, multiple script folders etc )    * Reliance on original mysql functions ( not mysqli or PDO )    * multiple frameworks, JQuery, various marketplace API's etc.  It has been a highly frustrating several hours trying to sort out where to begin with this mess, let alone how to fix the items I need. So my question is: What would be the best place to start or If this was dropped on your lap, how would you approach it? I know this is subjective, and opinions are what I am looking for, so any advice is appreciated.


What is the best method to start understanding BIG project source code?

> **Possible Duplicate:**   >  How do you dive into large code bases? Sometimes before developing new products we need to understand some existing products or existing source code. Sometimes to write another small module of that big project we need to understand that big source code. **In our case we need to study and understand a project with lots of files and folders. What is the easiest and most comfortable way to do it ? (especially for C and C++ and under Linux)**


How to fix very bad code?

> **Possible Duplicates:**   >  How do you dive into large code bases?   >  How do I handle refactoring that takes longer than one sprint? I have 2 files that cover 5000 lines of code. I have been ask to fix THE problem. The code is object oriented but use hundred of flags, is multi threads, uses variable name without meaning, has recursion problems, etc... The problem is that rewriting the code will take a couple of months and there is not specifications. The specifications are encrypted in the code. So the big question is do you have any ways or technique to fix/understand such bad code?


How to organize legacy multi page web app with tons of Javascript spaghetti

I have inherited of an application and need to reorganize and I hope I will be able to modularize the tons of Javascript that is everywhere. It is a **multi-page webapp**. Each page has a script tag in the header, which currently contains a **DomReady handler** which initializes all user event handlers for that specific page, and also very often contains from **1 to 10 javascript functions that are specific** to this page (meaning they are not useful anywhere else in the app). Then, there is a jQuery import on every page, plus an import of somthing like App.js which is simply a **very large collection of global functions** which are useful in many different pages of the application. Page of the application are quite different one from another, so it seems to make sense not to make every page load everything. I'm desperately trying to organize all this, and after investigating modern solutions like RequireJS, Browserify, simple lightweight MVP frameworks like Riot.js, loose coupling through Mediator pattern and so on. A lot of these seem to target single-page web applications mainly. I'm having a hard time to imagine how to reorganize this 40 page application where almost every page needs a **separate initialization, a few specific functions and a large number of general ones**... Also, the webapp can be installed on a user's own server and **individual page scrips behaviour must be customizable** through overriding some of the functions (or adding to the initialization, or the modules if they become modules in the future). What would an JS expert do ?


If TDD is about design why do I need it?

TDD gurus more and more tell us that TDD is not about tests, it is about design. So I know some developers who create really great design without TDD. Should they practice TDD then?


Emotional detachment from bad code

We all would like to work with good, easy to maintain code that follows best practices and design patterns. However, reality is far from ideal. After all, content on sites like The Daily WTF is not made up, and we all sometimes have to maintain code that is, to put it mildly, subpar in quality. I have problem working with that code. Of course, working with bad code is difficult from technical standpoint, but I have, well, emotional problem. When I have to, say, fix tiny bug in poorly designed application, I tend to focus on how bad the overall application is instead of how to fix simple bug. I think "jeez how one can be so stupid to write this". I treat work as punishment rather than challenge. It impeds my work productivity. How can I change my mindset to focus on task instead of contemplating how bad is the codebase I have to deal with? In this question I assume that obvious solution, i.e. fixing the bad code is not possible/applicable: it works, is too big, fixing it woud take too much effort, it will be soon phased out, was written by your boss etc. TO CLARIFY: I do not want to use overall code quality to justify spoiling it further. I assume overall code quality is wide known concern, but there just happen to be tasks with higher priority. Let's consider following example:               print "<h1>", sql("SELECT title FROM news WHERE id='$ID'"), "</h1>"      There are two problems:   1. Data and presentation layers are mixed   2. Code is vulnerable to SQL injection `#1` hurts maintainability of codebase, but do not cause any bugs or feature loss by itself. Moreover, fixing it, for example by moving to a proper MVC architecture requires significant effort. `#2`, on the other hand, may lead to data loss and is trivial ro repair (by escaping `$ID`). My question is, provided you are _assigned_ to fix `#2`, how focus on task instead of wishing "those guys writing Ruby on Rails apps are so happy".


Does TDD lead to the good design?

I'm in transition from "writing unit tests" state to TDD. I saw as Johannes Brodwall creates quite acceptable design from avoiding any of architecture phase before. I'll ask him soon if it was real improvisation or he had some thoughts upfront. I also clearly understand that everyone has experience that prevents to write explicit design bad patterns. But after participating in code retreat I hardly believe that writing test first could save us from mistakes. But I also believe that tests after code will lead to mistakes much faster. So this night question is asking for people who is using TDD for a long time share their experience about results of design without upfront thinking. If they really practice it and get mostly suitable design. Or it's my small understanding about TDD and probably agile.


How do you dive into large code bases?

What tools and techniques do you use for exploring and learning an unknown code base? I am thinking of tools like `grep`, `ctags`, unit-tests, functional test, class-diagram generators, call graphs, code metrics like `sloccount`, and so on. I'd be interested in your experiences, the helpers you used or wrote yourself and the size of the code base with which you worked. I realize that becoming acquainted with a code base is a process that happens over time, and familiarity can mean anything from "I'm able to summarize the code" to "I can refactor and shrink it to 30% of the size". But how to even begin?


How to justify rewriting/revamping legacy software in a business case?

I work for a great little software company which makes good revenue from our main software package. The problem for me is that it's almost unmaintainable. It's written in Delphi 7 (has upgraded versions over time) and has been worked on by a lot of developers over the past 20 or so years. The software lacks any meaningful architecture - there's no object orientation whatsoever, horrible amounts of cyclical dependencies and an over-reliance on global variables to name just a few things. Another huge thing for me is Delphi 7 does NOT support 64-bit. The problem here for me is that my management team don't care about technical things, they want to know why they should care. Obviously that's expected, so what I'm asking here is for some guidance, or tales, or pitfalls about this kind of thing. There's a few things I would love to include, namely for me, the length of time taken to debug/write a feature in "legacy" code, versus coherent, well structured OO code. Does anyone know of any blog posts or the like where this is talked about? For us in the company this is a huge reason. Despite being decent developers we feel like writing a new feature is just piling more rubbish on top. On top of that, even for me who has a decent level of understanding of the code, changing things is infuriating - a small change can have a ridiculous domino effect. Anyone have any experiences they'd like to share?


When is a BIG Rewrite the answer?

Just read the question about the Big Rewrites and I remembered a question that I've been wanting answered myself. I have a horrible project passed down to me, written in old Java, using Struts 1.0, tables with inconsistent relationships, or no relationships at all and even tables without primary keys or fields meant to be primary keys but aren't unique at all. Somehow most of the app "just works". Most of the pages are reused (copy pasted code) and hard-coded. Everyone who's ever worked on the project has cursed it in one form or the other. Now I had long considered to propose to upper management a total rewrite of this horrendous application. I'm slowly attempting to on personal time but I really feel that this deserves some dedicated resources to make it happen. Having read the articles on big rewrites I'm having second thoughts. And that's not good when I want to convince my superiors to support my rewrite. (I work in a fairly small company so the proposal has the possibility of being approved) TL;DR When is a big rewrite the answer and what arguments can you use to support it?


Junior - How to understand the flow of the code?

_A junior asking..._ **First a rather large chunk of background** Assume you have done some programming and now you want to take the next step out in the real world or at least learn more. I have no mentor, not yet anyway, but I have no intention sitting at home and twiddle my thumbs. My idea is to study the vast sea of open source. The problem is to understand a project. You can see the files and read the code line by line but it is of little help since there is > 1000 files with > 1000 lines of code. It is like standing in the middle of a forest at midnight. Where do you go ? The Internet have a lot of ideas on how to get involved in open source. As a developer, it is assumed you have at least > 2 years of experience. You read code like a newspaper. Fluent and with great ease. This is not very helpfull since I don't have that kind of experience yet. My idea is to use UML to get started. This should show some interest too, and will generate good questions to ask. I will start at the top with the packages, the folders. For a given file the include statement (or import or ...) provide all required dependencies. Dependencies can be divided into external och internal. The classes is of various types like subclass, abstract, data, factory, template and so on. This provide more relations between classes. Once you know something about the structure you can start to understand the flow. Now you can start to see the forest. The UML diagram can be auto generated of course but I will learn so much more by doing this by hand. Learning is the key here. This is my idea on how to get started with an alien code base as a junior. I have just started so I would be very happy if you shared your view, ideas and experience. **My question is:** _Imagine you stand in front of an alien code base, what do you do in order to understand the flow of the code ?_ For me it is a just huge set of files, I can't really see the flow between them. I really would like to be a good developer and know I still have much to learn. Hope you understand. **Thanks !! // Jim G**


When do you rebuild an application or keep on fixing the existing one

> **Possible Duplicates:**   >  When is a BIG Rewrite the answer?   >  Have you ever been involved in a BIG Rewrite? I am at a customer where I have been tasked to fix a number of issues they have in their existing systems. These systems are all quite old and was built in older technologies to really low development standards. All of this makes it quite difficult and frustrating to properly maintain these systems, because of the two thoughts that often come to mind while working on this:   * A. It would have been so much easier / quicker to do this in one of the newer technologies.    * B. I would not have coded this feature like this. There are many better ways to design this application to make it more maintainable and better performing. (examples are bad OO design, code is often repeated, settings are hard coded, etc.. the list is long).  So under the circumstances I try to make the best of it and fix everything to the best of my ability without complaining too much, but my question is now: How do you decide when it is time to rebuild a system with newer technology, versus keeping on plugging holes in an old one? And how do you make a case for rebuilding? How can you persuade the powers-that-be it is necessary to rebuild the system?


How to manage and estimate unstructured requirements received from customers

A lot of the times during the bidding phase of a project I receive a software system's requirements from our potential customers in a very unstructured format from various sources [email, word documents, excel]. It is usually a bunch of "product development" guys from the customer's side who come up with these "proposed solutions" to the business problems they have. While they are the experts at the business domain, a lot of the times they don't have the solutions right. This results in   * multiple versions of the same requirement   * mixing up of two requirements into one   * a few versions of the requirement later down the line, the requirements which were combined together get separated out again, each taking with it some of the new additions How do you work with such requirements coming in and sort them out into proper use cases and before development begins? What tools can we use to track a particular requirement's history, from the first time it was conceived till the time it gets crystallized into a proper use case? Estimating work against requirements received in such a fashion is a nightmare which ends up in making mistakes in understanding the requirement correctly and estimating the effort against it correctly. Once we win the project, then the customers have given some more thought to their requirements and have been able to articulate it properly. What happens in this case is that some functionality gets dropped, some enhanced, some take a whole new turn. This basically can nullify some of the work item's estimates that were made before the project was won. I would be interested in knowing if there is any system by which we can build a tree of a particular requirement and how each branch resulted in a different estimate. Any tips, tools, tricks to make this activity more manageable? I'm just trying to get some insights from someone more experienced than I am in requirements management and effort estimation.


How do you accurately create estimates for programming projects given to you?

I am looking for some insight from you smart people on SO. I'm a relatively new developer (3+ years of experience) primarily on the .NET framework, and I'm absolutely terrible at knowing how to properly estimate even the smallest of projects. I know that it's going to be a pretty big hindrance to my upward mobility as well as my joy of programming if I don't figure out good tools, methodologies, approaches, etc. Therefore, I am seeking your knowledge and wisdom on this subject. I have heard of SWAG and have most of the time employed that to give my estimates in the past, but I don't feel comfortable just "feeling it out." Certainly, from my experience of doing similar projects I can recall how long it took me and give a relatively accurate estimate, but even that isn't always very accurate. Plus, it seems that inherent in every project are gotchas and unforeseeables to make estimating even more difficult. Thoughts?


Limit useless complexity in code

I have a question, to explain that, what better than an entirely fictional example? Let's say you are a young developer just being employed in a firm. All data is stored in a huge database (let's say 500+ tables with billion rows). Your boss ask you to make some consolidation queries stuff. So, you start making your query and, during the development process you learn a lot of conditions to add to your query. Result? Your query works pretty well, result asked is correct but is slow and not very easy to understand. Why? Cause the query, due to a lot of modifications became very complicated. After that, with checking that with a colleague who work in the firms since years, he wrote the same query than you but... easier to learn and faster to execute. So, in fact the main question is: how can we limit this useless complexity ? How can make code more logic in fact? Actually, my initial idea was to draw activity diagrams of code to see where are bottlenecks but I think a better approach is possible. Looking for Books, Links, Ideas, Approaches, Methodologies...


Are there any well-known quantitative approaches to evaluate a particular design whether it satisfies or violates the SOLID design principles?

I designed an application framework by considering the SOLID design principles and supported by design patterns. However, I wonder if there are any automated tools or well-known approaches to evaluate whether the SOLID design principles are satisfied or violated in the proposed design?


How to learn to make better estimates?

I suck at estimates. When someone asks me how long something will take, I don't even dare to make a guess since I will be completely off the mark. Usually I'm way too optimistic, and should probably multiply my guess with some large X factor... How can I learn to make better estimates? It's not taught at my uni, and even though we have deadlines for all laborations I never think about how long something will actually take. Which I should. For everyone's sake (especially mine).


How do you get users to rank their software enhancement needs?

I've inherited a legacy software system, and have been tasked with performing usability and system upgrades. While there's nothing bad with the system, from discussions with the users, there are "small" usabilty issues that need to be addressed. At this stage I'm the lone developer on this system, and apart from testing I don't use the system at all, so its difficult for me to know what issues may exist or are percieved to exist. I'm going to have some time to speak with them all and discuss what they percieve to be good/bad or indifferent about the system. Since its essentially just me for the time being my time is limit. So I was considering asking them to imagine that I'd only be able to do one change, have them all write privately what they'd want that one change to be, and then helping them rank those, but I'm hoping for other tips as well. What techniques exist for getting users to explain their wants, needs, and requirements, while also having them rank them by importance or desirability?


Entropy in large scale software systems

I work on a fairly large software system and over the years it has accumulated a lot of entropy. There is plenty of scope for refactoring but there is always pressures to build the next features upon what's already there. This adds to more entropy, because design choices for implementing new features are typically made by first accepting what's there and 'working-around' some earlier weaker design that is otherwise ripe for refactoring. What are some ways to manage this kind of complexity and build functionality without substantially weakening the structure of the system further. I know this is a very broad question and the approaches/solutions depend on the particular software system at hand, but I am still hoping there are some generic ways to manage the problem I am highlighting.


How clean should new code be?

I'm the lead designer in our team, which means I'm responsible for the quality of the code; functionality, maintainability and readability. How clean should I require my team members' code to be if we are not short on time? In my view, we should clean up old code we modify; adding a line to a method means you clean up that method. But what about new code? We could make it sparkling clean, so that if another coder comes along tomorrow and makes a small modification, she doesn't have to clean it up at all. But that means if no-one ever reads that piece of code again, we've wasted time making it sparkling clean. Should we aim for "almost clean" and then clean it up further on future visits? But that would mean not getting the full value for the understanding we had when we wrote it in the first place. Right now, I'm going for "sparkling clean"; partly as a tutorial for my colleagues who are not as picky as I.


Quantifying the value of refactoring in commercial terms

Here is the classic scenario; Dev team build a prototype. Business mgmt like it and put it into production. Dev team now have to continue to deliver new features whilst at the same time pay the technical debt accrued when the code base was a prototype. My question is this (forgive me, it's rather open ended); how can the value of the refactoring work be quantified in commercial terms? As developers we can clearly understand and communicate the value in technical terms, such a the removal of code duplication, the simplification of an object model and so on. But this means little to an executive focussed on the commercial elements. What will mean something to this executive is the dev. team being able to deliver requirements at faster velocity. Just making this statement without any metrics that clearly quantify return on investment (increased velocity in return for resource allocated to refactoring) carries little weight. I'm interested to hear from anyone who has had experience, positive or negative, in relation to the above. \----------------- EDIT ---------------- Thanks for the responses so far, all of which I think are good. What I want to develop is a metric that proves (or disproves!) all of these statements. A report that ties velocity to refactoring and shows a positive effect.


How do I survive in a Waterfall world?

I currently work in a company where the Waterfall model is deeply ingrained. We are pushing Agile principles but it's a long process. Meanwhile, I have to work in a Waterfall world with sequential projects phases. My question is about the analysis phase. I must provide a list of task and how long they will take. What techniques can I use to improve the accuracy/precision of my estimates, while fulfilling the requirement of having a detailed estimate up front? One example I know would be to use prototyping to get more knowledge before making the estimate.


Considerations before rewriting a software component from scratch?

A piece of software is a patchwork of old and undocumented efforts. There are no comments, no documentation, and the code is hairy -- it involves _Unix shell scripts that check for dummy files and then call SQL statements that call database procedures that modify data._ The original developers have left and we score a solid 2 on the Joel Test but I can raise it to at least 4 - yay... The code is reasonably error-free, but we constantly need to add new features into it which is highly error-prone because of the state of the code, so the deadlines slip and the efforts rise. **We want to rewrite this software in order to reduce maintenance and development efforts.** As part of the rewrite, we will introduce specs, comments, test cases -- all things that we currently don't have. It'll still be a bit complex afterwards, but no more than necessary. This is not a BIG rewrite because we are not going to switch languages or frameworks; we'll still need shell scripts (but fewer) and database procedures (but fewer). The implications are also fairly simple because we're in control of the installation sites and we can fully replace the old code with the new code at the flick of a switch. I know a rewrite is never good but I think these are reasonable counterarguments. Nevertheless, my concern is the typical danger of introducing brand new bugs instead of the old known ones, and also the danger of not implementing certain details because nobody even knows they exist or are needed. **How can I approach this rewrite in an efficient manner?**


How long do you spend on analysis? Is this analysis paralysis?

I am not very good at estimating how long a piece of work will take to complete. I am guilty of putting my finger in the air and guessing. Usually things are later than expected, however sometimes they are earlier than expected. For example, a recent individual task was delivered in four months instead of five months. However, I am usually late. I want to get better at this. If I say something will take four months then I want it to take four months or less and not four and a half months or five months etc. The next task I am approaching was moved to the top of the project plan within the last week because of external pressures (external to the department). The business area want to know exactly how long it will take to complete. I find it difficult to estimate because of the following reasons:   1. The system I develop is very complex. I inherited it a few years ago and the previous developer did not follow good practice e.g. SOLID, separating layers (business layer etc) etc.   2. The business requirements are not particularly well understood by the business area because the system is very complex and we have to take into account legislation, which is only guidance and completely open to interpretation.   3. We lack the appropriate tools e.g. testing framework, continuous integration etc.   4. I am a sole developer so I have no-one to really turn to for guidance or help e.g. with testing etc. Anyway I have read questions like this: How to respond when you are asked for an estimate? and this: http://msdn.microsoft.com/en-GB/library/hh765979.aspx. My manager has suggested that I spend one month doing the analysis for the next piece of work (it is complex). I think I could do it in a week (I usually only spend a few days). What should the Agile output of an analysis be? How long do you typically spend of analysis?


How do you get relevant and useful information out of a client in regards to a job?

A brief background on this specific question: > After meeting with a client and hearing all of their requests, requirements, > and other comments about a specific software job, planning out the software > functionality, design, and basic user experience, the client comes back with > a comment regarding, "That is not what we are looking for. You can't do what > we want to do." Now, I understand the concept that not everyone understands tech, and that some people are more visual than others and may need to see things before they can be sure about something. I also understand the process of revisions and other modifications to meet specific functionality demands or requirements that may only come up after you start putting things together. I mean, if everyone got it right in version 1.0, imagine how great a world this would be! **Given** : There is no magic formula for a guaranteed success rate when a lot of the work is artistic in the sense that the same set of directions can be interpreted differently by different people. I'm aware that asking the **right** questions is important, and I have done some research about what questions others are asking in similar jobs. I also have previous experience with clients (this isn't my first job), and through it all, I have developed my own little system for getting this information-- which has had a 99% success rate up to this point. Usually if I don't get it right the first time, it's fixed during the revision and modification process. I know I'm not perfect, but I've never really had a client flat out refuse what they asked for... So **how do you get relevant and useful information out of a client in regards to job requirements and specifics?**


Best supporting argument for refactoring

Currently I am working on a code best described as C code living in C++ body. However I haven't been able to convince power that be to re-factor on ground of ease of maintenance. What in your opinion is the best argument for refactoring the code.


Should I try to persuade my manager that code tidying should take priority over meeting deadlines?

My manager has tight deadlines to meet. The current project I am working on is currently on schedule, but I've noticed a couple of quite significant areas in the code that are really badly written. (Bits of code get called two or three times, when they only need to be called once.) The problem is, as far as my manager is concerned, the program works. As he sees it, there's no point making lengthy changes to code that will make us miss the release date, for no tangible improvement that he can see. He keeps saying "That's not a priority. It's working fine as it is." Should I keep trying to persuade him, or should I just do what he suggests and leave it? Why or why not? Note that how to persuade management has already been covered.


What is the way to understand someone else's giant uncommented spaghetti code?

> **Possible Duplicate:**   >  I’ve inherited 200K lines of spaghetti code — what now? I have been recently handled a giant multithreaded program with no comments and have been asked to understand what it does, and then to improve it (if possible). Are there some techniques which should be followed when we need to _understand_ someone else's code? OR do we straightaway start from the first function call and go on tracking next function calls? C++ (with multi-threading) on Linux


How-to convince company to start documenting for legacy software

It has been less than a year since I joined my current company. Their majority of sales have come from a single product that has been alive since the last 10 years. However, there is minimal (if at all) documentation. Not only do the developers in the company struggle with the lack of documentation but also there is a high amount of turnover, causing everyone to lose their time. This is because experienced developers have left the company and there is less and less resources to communicate/brain storm with. Without getting into too much detail, I have suggested to the previous manager that there needs to be some sort of documentation (at least an Architecture document) that outlines the product. I also suggested using JavaDoc and other automatic documentation tools. These suggestions were responded to by slight smiles and statements of the sort "We do not have enough time", "We need short-term improvements right now" and even "The code itself should be the documentation" from the programmers themselves. I have already wasted enough time trying to find out if what I needed per requirement/bug had existed in this big (really) code base. I am looking for any suggestions that you might give regarding the need of documentation. Or, rather, if this is a lost case for this legacy system or organization.


What exactly makes code "clean"?

I am an intern at a small software company, doing typical grunt work. Many tasks that the actual developers are doing are above my head however I finally got to see some real "action" and write some code myself. I will admit the task was perhaps a bit too difficult for me but I managed and my coded worked in the end. When my mentor was doing code-review he had said to me "Man, this part is ugly." When I said, "Why? Is something wrong with it?" he replied, "No, the code works, but it's just not clean code." The concept of of clean code is one I have run across a few times before, especially now since that I get to hang around professional developers. But what exactly is it that makes code "clean"? In other words what is the criteria? I have heard in formal mathematics, a "beautiful" proof, is one that is ideally as clear and as short as possible and uses creative techniques. Many people know that in literature, "good" literature is one that can express feelings effortlessly and elegantly to the extent that one can "feel" it. But one can't "feel" code (at least I can't) and I think most would agree that short code is not necessarily the best (as it could be very inefficient) or even that the most efficient way is always preferred (as it could be very long and complex). So, what is it! Please, try to enlighten me to just what exactly makes code "clean".


How to tidy up a massive spaghetti project

I previously asked this on StackOverflow, but was advised it was a better fit for Programmers. I have recently begun working on a codebase (as a Java developer) with the following characteristics:   * Roughly 800,000 lines of source (including whitespace and comments). Primarily Java, but also XML, PHP, Shell scripts, JSP, JS, HTML, CSS   * Frameworks: Mainly Stripes, a bit of Struts, and some quite old customised Hibernate (and I expect lots of other bits and bobs).    * No particular methodology for stories, sprints etc.   * No tests   * No build process   * No dependency management (everything is just setup in IDEA)   * Some very old code dating back as far as 2002   * No coding standards   * Masses of code redundancy, though given the lack of tests this is difficult to track down   * Multiple modules and inter-dependencies   * A massive 10,000 line XML file containing named Hibernate queries   * 'Dump-all' classes at the top of the inheritance tree containing references to multiple services that may only be used in a handful of child-classes (As an example, one class is extended by 573 classes. A particular service contained in it is used by only 3 children)   * Demotivated developers I know this a really open-ended question: Where would you start in trying to tidy up this system?


Arguments to non-technical manager for program upgrade

**My situation:** I'm currently intern in a big company, developing an automation tool (for company internal use only). There are about 30 persons in the team, but we are only 3 developers, all interns (in master degree). The core of the software and the UI were made by experienced employees but three years ago. **The problem:** A lot of the technologies used can be upgraded (.net 3.5 to 4.0, using LINQ for Database interactions, Forms to WPF ...) and the User Interface is really not ergonomic. **What I want to do:** I would like to upgrade it and remake the UI, to improve performance, maintainability and ergonomy but my managers - business analysts - don't feed the need for improving a software that works fine. **Why I can't:** They want us to do new automation tasks, they think it would be a waste of time to do the upgrade and they are not sure we will success to do completely what I am aiming for. **My Temporary solution:** As I am motivated and really think the upgrade is necessary, I spend some evening and week-ends developing the new version, hopping once it's done I can show them and they will like it. But all this _working time_ is not payed and I don't have that much so I still hope to have like a full working week at the office to work on it. **My Question:** What is the best way to try to convince my managers that time used to develop the upgrade won't be a waste of time (knowing that all the technical arguments won't be understood)? I also don't want them and my coworkers to misunderstand my motivation with a tentative to show off or some other selfish intentions.


Understanding already existing complex code base

> **Possible Duplicate:**   >  What is the most effective way to add functionality to unfamiliar, > structurally unsound code? Till now, all I have worked on is with Java projects that I build from scratch (mostly course projects and some hobby stuff). But now, I have come across a huge code base of about 46000 lines spread across around 200 classes. Additionally there are around 10 dependent libraries. The problem is not only that I have never worked with someone else's code before, but I have not worked with such a huge code-base before too. I am asked to completely understand the code-base and suggest improvements to the existing design. Now, I am kind of stuck. **I start with some part of the code and then by the time I reach some other part of the code, I have lost the working details of the previous part.** I could really use your suggestions and experiences to deal with this issue. How do I proceed/document the details of the classes to understand the code better? Edit: This is a university level research project. Students have developed it over couple of years and the bad part: The students who wrote this have already graduated. The existing documentation (only in the form of Javadocs, not UML stuff) is a lot but not helpful in terms of understanding the application design.


Why are deadlines always so short?

I'm a junior developer in a small company (in a team of 2 developers). Everytime we are asked to implement a new feature:   * the deadline is set so that we just have time to do the development: there is no error margin (if something takes a little bit more time than expected, we are late) ; almost no time for tests (we are pretty sure there will be bugs) ; no time to refactor anything    * we are asked to start the development before the features are completely specified, so new things to do show up but the deadline stays as it is The result is that we deliver software that has bugs and the technical debt keeps growing. We use technology that was considered as a recent version in 2006 or so. There was one release that I remember very well. When we did a demonstration to the boss, he told us "What!?? You took two weeks to produce that?!" and all we could answer was "No, in fact it took us three weeks". I had a meeting with him and another junior developer (that quit the company because of this said meeting!), and he basically told us that he was not happy because what we released was crap. The technical debt and the need to refactor were so big in the parts that we had to modify (but we were told not to refactor because we have no time) that:   * we had to add a layer of bad code on top of the already bad code;   * we took much time to try and understand completely incomprehensible code.  I don't feel like I'm responsible for this bad release, I think that it's the boss' responsibility to hire good developers that, at least, understand the basic principles of OOP. But hiring juniors is so much less expensive... He is already saying that we are late for the development I'm working on at the moment. He spent more than one year to "redesign" a tool that was already present in our application, but now he wants us to implement it in two weeks. I personally think that if we want to do it correctly, we need at least one month, or maybe even 6 weeks. I don't know what to do, because I think that the boss thinks that we are just slow and ineffective. That's not the way I will get the raise I think I deserve. Why is it like that? That doesn't seem so hard to understand that if I need x days to complete a task, I can't do it in x/2 days, even if you say "please" and ask with a smile. That seems so obvious that the deadline will be missed and/or that the quality requirements won't be met. I don't need to know how I can explain to my boss that software development is a longer process that just clicking an icon. Because I hope he already knows that.


Boss doesn't believe my time estimate... advice/backup?

I'm working at a startup software company -- 3 developers, less than 15 employees including the CEO. We deal exclusively with Windows Mobile, the .NET CF, and passing the information gathered from our handheld application to and from our website. My director and I just had a meeting over an urgent project that hasn't begun yet, but it should probably get on a roll soon if we are to meet delivery deadlines for a prospective but very powerful and influential client. He proceeded to explain the project to me as follows:   * The new project will consist primarily of a .NET CF app that allows the client to conduct multiple soil samples over the course of a single session.   * The area being sampled by the user should be shown on a map of appropriate size and scale.   * The map should be dynamically split into grid squares of a size set by the user (in acres).   * On each grid square, the user will have the ability to take notes and mark individual points via real-time GPS from the on-board receiver.   * In addition, functionality should exist to help point the user to any grid square given their current position.   * All information collected should be easily retrieved and read in a very user-friendly manner on the customer's handheld device -- a device which we provide -- at any time.   * All information collected should be easily sent -- through ActiveSync, wirelessly, or what-have-you -- to our website where it should be viewable/editable in an interface similar to that of the handheld device. With that description in mind I thought things over (albeit rather quickly). With our current staff size, limited budget, and limited resources, I projected that such an endeavor would take roughly 9 to 18 months. Forgive me if I'm off in left field, I'm a recent CS grad and pretty new to the "real" world. However, the project is currently only realized in my director's head, with no design documentation or specs. My question here is, how far off am I, really? Once again, my director -- who has no background in software or IT whatsoever, but is a subject matter expert insofar as soil sampling goes -- put the project at about a 3-month duration. Keep in mind that we're currently using an unsupported SDK for the rest of our GPS and GIS needs, and ESRI products are almost too far out of range for us. Current functionality in our other apps goes give us a leg up, with the ability already in place for us to draw areas, polylines, and plot points on a map. I'm just kind of confused/afraid here, wondering if I'm completely wrong or if I'm right but just without confidence. Any and all advice is appreciated. Thanks!


What to do with a not well organized application?

I'm a newly graduate programmer and just got hired before my graduation. In the office, I used to create and revise modules of some applications developed by other programmers in our company. The problems I encountered with their applications are:   1. Unnormalized database at it's best, they've broken all the rules of database normalization, Codd must be angry.   2. 50% of the content of the database is literally NULL (they should have default value I swear).   3. One stored procedure is used in all database transactions, full of "if-else" statements.   4. They are reinventing the application settings in .NET WinForms, they create their own file which contains everything they want. I think they are very fan of VB6 or maybe they don't study really, they're guessing how to achieve something.   5. No error handling! Clients sometimes report "Exceptions" which they shouldn't be seeing.   6. Web files and Windows Forms are not organized or grouped according to their use.   7. Naming convention, there are Camel case, pure lower case, with and without underscores and abbreviations.   8. Bad programming practices like database transaction in each iteration of a loop.    9. They developed website with SQL injection in mind, they welcome them.   10. HTML elements were not used according to their sematics.   11. CSS are not optimized for different browsers.   12. They include several versions of jQuery in one HTML! . . . N. Many more! The worst thing is, I felt being blamed for it's fragility. I mean, when I add code, there are times that it ends up with error, sometimes because they did not create constraints or they allowed duplicate data. The system is so fragile and dependent to one another, it's like walking in a field with landmines! (THIS HAPPENS SOMETIMES, THIS IS NOT THE REAL ISSUE) What should I do?


What should I do if I don't have any formal spec?

I recently was assigned to a task, but it says only a couple of words, like, do it as it made there, with no actual spec attached. What is the best thing to do in that circumstances?


How to quickly understand a huge piece of code

(This is a general question but I think is important.) How do you quickly understand a huge piece of code, say, a project with tens of thousands of lines of code (written by other people)? Are there any useful source analysis tools (for example, call graph visualizer) or IDEs that may be helpful? Any techniques are also welcome. Thanks.


When systems get larger and larger, how do you keep a global understanding of your system?

Today I realized painfully that for some decisions you need a good overall understanding of the system. Otherwise, the risk is too high that your assumption turn out to be wrong. Imagine that you are a developer for an online web shop. To understand the system, you have to understand many connected subsystems, for example:   1. How to receive and process product information from various suppliers   2. How the customer can search and order products on your web shop   3. How the orders are processed and managed by your customer service   4. How your SAP system handles the invoicing process   5. ... The larger the system becomes, the more you have to understand. If that knowledge is lacking, sub-optimal solutions where developed when specialized teams worked together. Specialized teams, which only understood their part of the system in detail. To deal with that problem, our company changed the strategy, so that one development team always has to be responsible for all aspects of a feature. Even if it involves the complete process chain. (It is kind of a feature team, but not from teams working on different subsystems.) **What are effective strategies for developers to keep their system and operational process knowledge up to date?** I think good system documentation is a key, but I'm afraid that there is a point where the human mind cannot scale as fast as the system involves. At some point to have to simply, but that simplified assumptions can turn out to be costly mistakes. When you have to implement and maintain the code, you just have to know the exact details. As a developer, I currently have to face a difficult conflict of interests:   1. I need to spend more time to understand our system and operational process.   2. I need to develop and maintain our code. As time is limited, 2) mostly wins. The result is that I mostly gain deeper knowledge along the way, and some half knowledge from casual conversations. Do you know how huge companies like Amazon solve that problem? I would assume that no single human is capable of understanding such a complex process, and be able to contribute code at multiple subsystems at the same time.


I have 200k lines of poorly designed code, will units tests or integration tests be more valuable?

I've inherited a lot of poorly designed code; the code has no tests. I am putting tests in place before I attempt a major refactor, but I have run into a problem with my unit tests. The problem is, I will unit test a function, and then later decide that function is a liability. I will either get rid of the function, or change its purpose. Either way, the original function gone and the unit tests fail. Should I spend a lot of time putting unit tests into a design I will change dramatically? Wont those unit tests be useless after a major redesign? Would integration tests be more valuable? I can chose program features I know will not change and create some integration tests to ensure they, indeed, do not change. I might change all the code behind the feature, but the feature should still work, and the integration tests should still pass. I know there are lot of questions on similar topics. I am asking specifically about the use and value of unit test vs integration tests in messy legacy code.


Should We Code for Performance or Stability?

There is a point in time where you make design choices and debate them with management. In my case I have to debate my positions and design choices with senior management but it is frustrating that management only strives for performance while I think stability is a must while performance can be achieved later. E.g. We are facing a design choice to make a recovery mechanism due to lack of transactionality in certain processes i.e. we need to guarantee transactionality of a those processes making them complete fully or rollback the changes it made to database. The current code makes this difficult because we are using stored procedures that manage their own transactions. This means that if the process calls 3 or 4 stored procedures, there is 3 or 4 transactions and if we want the recovery process we need to rollback those changes (yes, they are committed at that time, this means that we need to make more transactions to the database in order to leave it in a consistent state or at least somehow "ignore" those records). Of course, I wanted to remove the transactions from the stored procedures and commit the transaction in the code after the process ends or rollback there if the process has exceptions. The case is that management thinks that this approach will make the process slow and also will impact greatly in our code. I think this is correct but also I think that making the rollback process ourselves is plainly reinventing the wheel, error prone and IMHO it will take too much time in stabilize. So, after the previous example, **What could be the most beneficial approach in such cases?** I mean, I want a Win-Win situation but I think it is just plainly impossible to agree on this because every time I want to talk about it I get responses like "there should be another way", "you should not tell me there is no way around", "this is not factible", "the performance will degrade", etc. and I think I will end making this faux recovery process just to comply with management. OTOH I could be wrong and I should do what is told to me without complaining.


How much poor quality code should a junior put up with?

I am a junior developer who has been working at a new job for a few weeks. I am working with a large framework for scientific desktop software, adding pieces of functionality. While there are general aspects of the job that are appealing (such as the people and the pay), I have to admit that I find the work unrewarding and boring. I feel disappointed because I do like programming in general. I'm concerned that if I "settle for" this job - or this position within this job - I may lose my love of programming. I think that I am getting frustrated because it is hard to get feedback on the correctness of my code that I'm writing. It is hard to unit-test. Testing involves firing up the program and stepping through the code. I do not feel like I have a mentor. My impression of the code base is that it does not use much in the way of OOP principles. (Perhaps many of the people who have worked with it are more experienced as scientists than developers.) Do you think I'm being soft/naive/idealistic and should continue to work with this code for a year or two (and do more personal projects on the side)? Or do you think that I should go with my gut feeling and try to find a new job where I can work with higher quality (maybe TDD) code?


Best way to quickly explore/grok open source C/C++ projects?

I'm looking for a suggested workflow for quickly being able to download various c/c++ open source projects and then begin intelligently navigate sources. "Intelligently" means being able to jump around to usages, definitions, implementations of a particular symbol, both in the downloaded code base, and also the headers of referenced libraries perhaps installed in /usr/local or /System/Frameworks etc. this code jumping could be driven by etags, ctags, gnu global, eclipse CDT indexer, Xcode's indexer, I'm open to anything, but I have no idea what is the best solution for most cases out there. Shortly afterwards I would like to begin stepping through unit tests, examples, demos in the debugger so I can better grok how the code works Obviously, this isn't going to be possible for every project out there.. but most of the projects I am interested in are either autotools or cmake based -- In general, I don't really care what IDE (emacs, vim, xcode, eclipse, etc) I use, and I don't mind running a command line debugger -- I just want to quickly download a C/C++ project, "fool around with it" at a source level, and then move on if its not interesting. My question is particularly directed to the guy or gal super hacker who routinely explores several different large C/C++ projects every few days/weeks --> how do YOU productively do this? (My background/experience level is that I know enough about c/c++ tooling to get things to build/or debug a broken build on several different os'es usually within a few minutes, but it can take hours before I get to the point where I can take a large project and get to the point where I am stepping through examples in the debugger. I have a feeling this is because I try to use modern IDE's, but I'd be better of just using 'old school' tools. when dealing with jvm stuff -- it is usually pretty quick to get to a place where one can get intellij to grok code and start debugging -- I'd like to replicated this as much as possible in C/C++) thanks!


How to document legacy code (shell scripts)?

I got involved into a project where we are taking over a bunch of legacy code. Code is basically shell scripts and PL/SQL packages/procedures/functions. There is no documentation how the code works and there is also no comments on the shell scripts. I was thinking that first thing to do is to get an understanding of the dependencies of the code, how to scripts call each other and so on. Do you have any suggestions what would be the best way to document the dependencies between scripts and PL/SQL code? What would be the most suggested tool for this (for diagrams, perhaps)?


How does one determine whether or not to rewrite poorly-designed code?

> **Possible Duplicate:**   >  When is a BIG Rewrite the answer? I'm on a small team that's been handed a poorly-written, half-finished 2D Java game. Our objective is to do as much as we can to make it better in about 11 weeks. I'm pretty sure the code is not maintainable and I need to decide if I should pitch the idea of a rewrite (near rewrite, anyway). For example, the Main class, which is an applet, has most of the game logic just thrown into it. Keyboard and mouse events are handled with huge if/else blocks, none of it is commented (the only comments are the sections of code that have been commented out), and all of the drawing and animation code is just in one huge chunk. Images are loaded in a separate class that just goes through each file, each on a separate line, and reads the image into a static Image variable. This all seems like poor design. We have until the end of the semester, roughly 11 weeks, to make the game better than it is right now. It's playable but severely broken in spots. I've currently been assigned a small feature to implement: a clickable main menu instead of one that's controllable by keyboard only. On one hand I know I'm capable of implementing this but on the other I'm afraid to try to add new features because a) the more stuff we add the more likely it is that the program will break because of the bad design choices and b) the more I'll be adding to the mess that's already there. I took the weekend to try to duplicate the basic game functionality with a different design (to see if it could be done quickly enough). I'm able to load and cache sprites, create game entities and move them, and keep track of the game's state to determine which keyboard input to handle and what to draw on- screen. A spritesheet loader was next on my list (I found out that the game art isn't in sprite sheets but each is in a separate file). A trusted friend said that it might be better to have to maintain the old code but looking at it it's too brittle. We could refactor as we go but I think that would be difficult too. Our group is meeting this Friday. I planned to discuss the idea of an overhaul and present what I've been working on but now I'm not so sure. I feel like it's a simple-enough 2D Java game that once we put together a solid base that it would be a lot easier to add features but we'd have to redesign the base code pretty quickly, probably in two to four weeks or thereabouts. I'd like to think that we can do it that fast but I'm not completely sure. I guess you could reduce my question down to this: how do you best determine when to maintain poorly-designed code and when to spend some time starting almost completely from scratch?


Estimating Coding/Development efforts?

> **Possible Duplicate:**   >  How possible is it to estimate time for programming projects? We have designed a User Interface (UI) in HTML for an Intranet Application.it took almost 30 days to make it,how we should estimate the development effort(coding) for it,is there some ratio we can use to estimate,it need not have to be exact but some estimate would help.


What to do when you inherit an unmaintainable codebase?

> **Possible Duplicate:**   >  Techniques to re-factor garbage and maintain sanity?   >  I've inherited 200K lines of spaghetti code -- what now? I'm currently working at a company with 2 other PHP developers aside from me, and 1 junior developer. The senior developer who originally built the system we're all working on has resigned and will only be here for a matter of weeks. The other developer, who is the only other guy who knows anything about the system, is unhappy here and is looking for a new job. I'm very real danger of being left behind as the only experienced developer on this codebase. Since I've joined this company I've tried to push for better coding standards, project documentation, etc and I do think I've made some headway, but the vast majority of the code is simply unmaintainable and uncommented. A lot of this has to do with the need to get things done fast at points in the project before I joined, but now the technical debt is enormous, even with the two developers who do understand the system on board. Without them, it will simply be impossible to do anything with it. The senior developer is working on trying to at least comment all his code before he leaves but I think the codebase is simply too vast to properly document in the remaining time. Besides, when he does comment it still doesn't make things as clear as it could. If the system was better organized and documented I could probably start refactoring it incrementally, but the whole thing is so tightly coupled that it's very difficult to make any changes in one module without having unintended knock-on effects in other modules. Naturally, there's no unit tests either, and I honestly don't think this codebase could possibly be unit tested anyway given how it's implemented. There also never seems to be enough time to get things done even with 3 developers and 1 junior developer. With one developer and one junior, neither of which had significant input into the early design of the system, I don't see how we could possibly get anything done with keeping the current system working, implementing new features as needed and developing a replacement for the current codebase that is better organized. Is there an approach I can take to cope with this situation, or should I be getting my own CV in order as well at this point? If it was just me and the junior designer who would be left I'd go for the latter option almost without question. However, there's a team of front-end developers and content managers as well, and I'm worried what would become of them if I left and put them in a position where there would be no developers at all. The department might just be closed down altogether under such circumstances, and then I'd have their unemployment on my conscience as well!


Familiarize with unknown source code

I have to continue feature development, issue fixing of a halfway completed code base. There is a no documentation, all developers had left the company. The technology stack is somewhat familiar to me (Spring, Hibernate, Web Services (Rest, SOAP), MySQL). Also there are non descriptive JIRA items that the team had worked over 3 years. Seems code has implemented in consistent way like layering, ant file per project, DAO classes. I would like to get feedback from all our experts. What should be the approach to get familiar with the project? Do you recommend to use profilers, bug track tools like Sonar to get some hints? Any other approach I can try out?


Can I refactor "safely" without specs?

I have inherited a legacy web application many years which:   * Does not make use of Object Oriented principles, even though the language would permit it   * Has no unit tests, nor any sort of test suite, automated or not   * Generally ignores various general best practices making the code very hard to read and maintain   * Splits its workings (including code for business rules) across the web application, database views and stored procedures. Some of the code is even externalized in that outside applications (not under me or my team's control) often read _or write_ directly into the database   * Has only the barest documentation (including some I've created)      * No documented technical or functional specs to speak of either   * Has changed rules so many times and so fast that no one truly knows how it's supposed to work anymore. Rules are stacked on as missing features or specific cases are discovered on a daily basis.   * Happens to be the most business-critical application of the company   * Is still constantly evolving Refactoring almost always comes with the main suggestion of adding unit tests to make sure you don't break anything. How do you do this when you do not even know how the thing is supposed to work (and no one else can tell you _for sure_ )? Is this a case where you'd need to go back to square 1 and slowly, iteratively, as new features are requested, ask for specs focused on the modified section and _then_ refactor what's there? Is there any other way to deal with this situation? This question focuses mostly on the lack of specs in opposition the refactor safety rule of creating unit tests to ensure the rules are respected throughout refactoring. That said, a few more bits on the situation beyond lack of specs:   * The "best" programming structure found in the code so far is the function. They tend to not be self-contained and call on many global variables (even local variables were erroneously set as global variables risking unexpected behaviors). I get the feeling the first step might be to refactor _this_ to even allow unit testing.   * The issues mentioned apply to the whole application, the database procedures and even sister applications. Everything is intermingled together and almost never through interfaces. It's still possible to find   * Code tends to be duplicated in various places. It happens with business-rules code, meaning you may get different results depending on _where_ in the application you call up a feature. Obvious maintenance complexity and risk.


Working with a large, messy object

I have been handed a very cluttered, "One Ring" object (one object to rule them all). The OR class has 40 fields. These fields map to 16 different objects (the OR has all the fields from the 16 objects concatenated together. Some of the fields are common to all objects, some are unique to individual objects [all of the 16 objects are descended from a common parent]). The OR points to a catch-all table in a denormalized SQL database. I've been asked to write an adapter for this that will take random instances of the 16 objects, map the fields from a given object to an instance of the OR, and send it on its way. Oy. Changing the back end or the code is not an option (I tried). As I'm sure is no surprise, this beast is a nasty thing to manage. I would love to hear some thoughts about ways to help make working with this a bit more manageable. I'm primarily concerned with code maintenance: comprehension and readability. I know whatever gets implemented will be far from perfect, because I'm basically trying to make garbage look pretty. That said, for now, I have to live with it, so I'm trying to make my side of the train wreck a little bit more livable.


How to educate business managers on the complexity of adding new features?

We maintain a web application for a client who demands that new features be added at a breakneck pace. We've done our best to keep up with their demands, and as a result the code base has grown exponentially. There are now so many modules, subsystems, controllers, class libraries, unit tests, APIs, etc. that it's starting to take more time to work through all of the complexity each time we add a new feature. We've also had to pull additional people in on the project to take over things like QA and staging, so the lead developers can focus on developing. Unfortunately, the client is becoming angry that the cost for each new feature is going up. They seem to expect that we can add new features _ad infinitum_ and the cost of each feature will remain linear. I have repeatedly tried to explain to them that it doesn't work that way - that the code base expands in a fractal manner as all these features are added. I've explained that the best way to keep the cost down is to be judicious about which new features are really needed. But, they either don't understand, or they think I'm bullshitting them. They just sort of roll their eyes and get angry. They're all completely non-technical, and have no idea what does into writing software. Is there a way that I can explain this using business language, that might help them understand better? Are there any visualizations out there, that illustrate the growth of a code base over time? Any other suggestions on dealing with this client?


Next steps for developing new product

I was hired about a year ago as the lead (well, really the only) developer on a new project/product we will call product "B". Product B was designed to pursue a new market for the company. This company has had great success with a similar product for a different market. We will call this other product "A". “A” is almost 5 years old now and is reliable. The two markets don’t necessarily overlap, but a lot of the core functionality in A could be re-purposed to work for B. My deadline to pursue this new market for product B was pretty aggressive. We had to demonstrate certain capabilities to potential clients quickly and show them that we were a serious competitor in the new market. To expedite the development, we took the shortest route to create a new product. We started with a deep copy (a branch) of the companies' product A and re-purposed it as B. This approach made a lot of sense given the time constraints as we inherited a lot of overlapping core functionality and infrastructure for free. We removed a bunch of features and options that didn't apply, left some things that carried over, and added a bunch of new features that were needed to secure these customers. It wasn't a perfect transition, but it was good enough. Product B has been around for about a year now, and things are looking good as we have secured two customers with several more potential customers on the horizon. What are the next steps? From a “best practices” perspective, it doesn't seem like a good strategy to continue developing product B as a copy of product A. It’s not a solid foundation to build a new product. We accomplished our immediate goal by creating a “product” and demonstrating it to potential clients. Now, shouldn't we take a step back, find out what the users really want and refine our design? We really don’t have a “new product”. We created some “vaporware” for a couple of demo installs. Unfortunately, I get the impression from management that they think we have a new product to develop and sell and there is no time to step back and refactor and refine. Why would we spend time and money redesigning when we already have something we can use and sell? Here are my issues:   * Since it was created from a copy of A, the product B code base is littered with artifacts and “technical debt” from product A. Some of this code is no longer reachable. Some of this code is reachable, but maybe the business logic does not make sense for product B. For example, there may be lookups against empty tables in the database or checks against things that don’t exist. This type of logic not only hurts performance, but it also a maintenance nightmare. I’m going to estimate that we’re actually using 35% of product A’s code base, and the rest is baggage.   * Management thinks it was smart to create B from a copy of A: “It will save money since code can be reused between the products.” If a bug is fixed in A, why can’t it be merged into B? Or if I develop a new feature in B, why can’t it be merged to A? This argument is flawed. Although B was created from A, it was done so over a year ago, and A has a dedicated team with 4 developers. I am alone on product B. The code branch for A continues to diverge from B. Now, it’s very difficult to merge anything.   * Finally, I feel as if we've put unnecessary constraints on ourselves by starting with a product that's already 5 years old. Some aspects were designed very poorly and will no doubt create the same problems with a new user base. Let’s take our lessons learned and use this opportunity to improve the design instead of copying crap. Also, let’s utilize new technologies where it makes sense - a lot of things have changed in 5 years!  How can I convince management that we need to refine our product – most likely from the ground up? My boss thinks in terms of time and dollars, and I feel that I am going to lose this debate if I’m not careful. Can this type of effort be quantified and put into management terms? I've been reading up on “emergent design” and I’m trying to approach my argument from the angle that we don’t have to deliver everything all at once. Let’s focus on small pieces of working code with the most business value.


How do you write good software while learning a language?

Quick background: I'm in an advanced C++ course for a study abroad program. The problem is that I don't have any background in C++. I have a modest C background, but I'm starting to think I have more holes in my knowledge than I knew about. My problem is that I'm writing really shitty code right now, but the university has an automated testing system that always seems to stump me in some way: does your code meet all the automated tests (no points if not), did you use the naive solution in terms of time or space (you get less points for this), do you have ANY memory errors (usually no points if so). So, my question is what do you do during development that leads to verifiable, integrated results? Is there a better way to learn and develop so I'm not always cornering myself with features of C/C++? I'm looking to develop a method of software engineering for myself in which I can get full points for these homeworks in less than 10 hours per week (I'm currently spending 15 hours and not getting full points).


What can I do to maintain respect for a poorly written codebase?

In my job I have to maintain a poorly written codebase which is both hard to understand, has tons of comments that are just plain wrong, has a bunch of weird decisionmaking going on in it and a whole lot more. I primarily do bugfixing which ranges from finding that little comment somewhere in the code that makes some random part not work, to understanding complex circular dependencies with some kind of singleton'a'palooza going on, and occasionally I actually get to write some real code, which is when I'm the happiest. But I'm concerned about the bugfixing witch I must confess many times ends up in being sloppy patchwork because I don't have the time or the mental fortitude to look at the horrendous code anymore. Now the biggest problem this project has is not that I'm just a whiny guy, I'm most certainly not alone in having above mentioned sentiments about the codebase. The biggest problem is probably the cost of maintaining it... But i digress. What I'm wondering is if there is some practices that I and my colleagues can try use to regain some respect for the codebase we've inherited and are working so that we don't walk down the path of creating more code rot?


Inheriting projects - General Rules?

> **Possible Duplicate:**   >  When is a BIG Rewrite the answer?   >  Software rewriting alternatives   >  Are there any actual case studies on rewrites of software success/failure > rates?   >  When should you rewrite?   >  We're not a software company. Is a complete re-write still a bad idea?   >  Have you ever been involved in a BIG Rewrite? This is an area of discussion I have long been curious about, but overall, I generally lack the experience to give myself an answer that I would fully trust. We've all been there, a new client shows up with a half-complete project they are looking to finish and launch. For whatever reason, they fired their previous developer, and it's now up to you to save the day. I am just finishing up a code review for a new client, and in my estimation is would be better to scrap what the previous developers built since and start from scratch. There's a ton of reasons why I am leaning toward this way, but it still makes me nervous since the client isn't going to want to hear "those last guys built you a big turd, and I can either polish it, or throw it in the trash". What are your general rules for accepting these projects? How do you determine whether it will be better to start from scratch or continue with the existing code base? What other extra steps might you take to help control client expectations, since the previous developer may have inflated those expectations beyond a reasonable level? Any other general advice?


Refactoring several huge C++ classes / methods. How to start?

> **Possible Duplicate:**   >  I’ve inherited 200K lines of spaghetti code — what now? I'm dealing with legacy code. It contains some BIG classes (line count 8000+) and some BIG methods (line count 3000+). For one of these methods I wrote a unit test that covers at least some code. This function has no specific structure, it is a mess of nested loops and conditions. I'd like to refactor but still I have no idea how to start. I actually started by extracting one single function. In the end it had to have 21 parameters :-/ Should I ...   1\. continue extracting awful functions knowing that in the long run I will succeed?   2\. start extracting even bigger functions? So I expose the structure of this monster and then I can start the real refactoring.   3\. only extract small "good" functions (and / or classes) just because I am a helluva clean coder?   4\. do something completely different?


How to manage stress from ongoing difficult maintenance?

I recently signed on to a contract where I am supporting an aging legacy system. The system is a collage of .net and VBScript components. Part of it operates as a web application; part of it operates as a Windows Service. As anyone on this site can tell you, it is possible to write great code with legacy technology and it is possible to write terrible code in new technology. The project I'm working on is some of the worst spaghetti code I've ever seen. It is over ten years old, and has been developed, supported, and maintained by a half-dozen unrelated companies. There are few code comments, and it's like each developer didn't know what the previous developer was doing. Yet somehow, the program works most of the time and is a critical part of a big business. There are hundreds of thousands of lines of code in the system, and here's how it works: Each week, my client gives me several bug reports to review at the beginning of the week. I am told specifically not to try to improve the design of the system, but to make the smallest change possible to fix each bug. Here is what bothers me: First of all, it is very taxing just to try to read the code and discern what it does. There are iframes galore and very odd ways of interfacing browser to server and server to DB. It is common for to take days to find the corner of the codebase where a bug is caused, and if the fix isn't trivial, it can take days more to understand the related parts of the codebase. It feels like pushing a rock up a hill for a living. The work is very exhausting mentally. It is difficult to maintain focus, and then I feel additionally stressed by wanting to perform my best while being tired and unfocused. To top it all off, I know the whole time that I am working on a bug that as soon as it's done, I am to start all over with another bug. The work is very remunerative and I would like to fit myself better to it. How do some of the more experienced developers handle this sort of stress? **Edit:** I think that Robert Harvey brought up a good point in the comments below: that I could be stressing myself with my own expectations. Much of my past experience has been with green-field development, so perhaps the slower pace of maintenance. Perhaps this maintenance requires a different mindset and way of thinking. Also, I take great exception to the idea that I'm inappropriately asking for help with my mental health. I do understand that psychiatry is now considered a medical discipline, but that doesn't mean that any and all questions about managing stress and being happy should be handled only by mental health professionals. That's just silly.


How to restructure Python frameworks

I just joined a group of five developers (non-professionals) working on a medium sized Python framework (> 50 modules, > 10.000 lines of code). The project has no documentation whatsoever and there are no coding conventions of any kind. My job is to   1. get an overview of what the framework does (theoretical physics calculations),   2. write a detailed documentation for the current code,   3. define development guidelines,   4. design a new software architecture,   5. perform code refactoring. Unfortunately, I'm not used to programming languages with a dynamic type system in such large projects (until now I've used Java for such purposes and Python for shorter scripts). Speaking in terms of anti-patterns, the code is pure spaghetti code, contains a god class and lots of copy-and-paste programming. In my oppinion, the code has degenerated to a point that is unmaintainable. However, rewriting the entire code is not an option. In "AntiPatterns: Refactoring Software, Architecture, and Projects in Crisis" William Brown et al. suggest the following steps for code refactoring, when adding new code in such software projects:   1. Control access to member variables (in Python I would use properties).   2. Avoid duplicated code.   3. Reorder function arguments to improve consistency.   4. Remove code that is, or may become, inaccessible.   5. Rename classes, functions, data types to improve consistency and set standards. Step 1 seems to be somehow un-Pythonic to me and steps 2-5 are trivial. I have resigned at trying to figure out the big picture. Instead, I am approaching the issues one at a time. However, I am constantly stuck at trying to resolve the insane amount of object coupling. I am uncertain if my approach is a good idea at all, as I have no experience in software restructuring. It is also hard to ask a specific question as I am stuck in the beginning of my work. I would appreciate if someone could provide insight into best practices in this topic. * * * **Edit:** This question now focuses on the approach of restructuring Python frameworks instead of simply getting an overview.


How Much Of A (Broken) Legacy Framework To Keep

I've inherited a hosted system (system "A") which can be used to manage products, inventory, and orders, and can send those products to various third- parties. Quite simply, system "A" doesn't work. The product and inventory systems are slow, convoluted, and buggy. The third-party integration doesn't work at all. The code is an unholy, spaghettied mess, so fixing things is not simple. My task is to try and salvage the system into something usable, and my original plan was to just refactor, refactor, and refactor some more until the system worked. However, my company also has a separate system (system "B") that we use to build e-commerce websites. Among other things, system "B" can manage products, inventory, and orders as well - just in a lesser capacity in some cases. System "B" is also constantly being worked on and updated by a team. My new plan is to essentially throw out system "A", and re-create it based on system "B". Since my refactors would have eventually restructured system "A" entirely, I figure I can just save time by starting over with a different, existing framework. However, if I go that route, I would still have to re-code the third party integration, and minor functionality that system "A" has and system "B" does not. Right now, system "A" is basically defunct - nobody is really using it, so I do have the freedom of a slightly extended rewrite period if I choose. Is this a good idea, or should I stick with the original plan of refactoring system "A"?


What characteristics or features make code maintainable?

I used to think I knew what this was, until I really started thinking about it... "maintainable"... what exactly makes code maintainable? To me, if code must be maintainable that means we can expect to revisit the code to make some sort of change to it in the future. Code is always "changeable" no matter what state it is in. So does this mean code needs to be easy to change? However, if our code was scalable/extensible, there would be no need to directly change it, because it will "change" (adapt) for free and automatically. I've also seen code maintainability used interchangeably with coding standards. Using a consistent coding pattern or style, does this really make code more maintainable? More readable and more consistent? Sure, but how does this improve the maintainability? The more I try to think into this, the more confused I get. Anyone have a proper explanation?


First step in analysing a proposed system

A client asked us to automate his offline paper-based processes. He sent us a copy of the physical forms that he uses. Our team met and discussed how the navigation should be, what major components would exist in the UI. That's it. Problem is, we don't have actual "written" requirements. With a lack of an actual business/system analyst in our company, what are the steps that we should take to reach the point where we are ready to start developing the system?


What's a good way to manage long piece of code in files?

I am a web developer and at the moment am finding it hard to cope with long un-documented code written by previous developers in an organisation I work for. With the deadline gun always pointed at my forehead, it's doing my head in. I use aptana studio's search feature for some quick wins but it is becoming overwhelming to a point that I do not want to work with them anymore. Is there any quick/proven approach that I can take to help me with a scenario like this?


What can I do to get better at estimating how long projects are going to take?

I don't want to make life hard for management. I really don't. They're nice enough guys, but every time I am assigned a new project or task and get asked "how long do you think it will take to do this" I end up sputtering off ridiculous timeframes; "between a day and three weeks". I would like to believe that it's not entirely my fault: I am the company's sole programmer, I am relatively new to proper development (Was it only six months ago that I wrote my first unit test? sigh...), and I am working with a code base that at times is downright absurd. So I would like some advice. Obviously, experience is the biggest thing I lack but anything that would make me better would be greatly appreciated. I am looking for reading material, methodologies, maybe even actual tools. Any way that I can give my boss more accurate information without having to sit down and design the darn thing first is appreciated. Ok magic stackoverflow genie, what have you got for me? **EDIT:** @Vaibhav and others suggesting I take time to research and sketch out the system I agree with you in principle, but how do you balance that with real-world constraints? When you're a one man show or even a part of a small team "I will need 2 days to build an estimate" is a real deterrent when you can fight 4 fires in the time it takes to get a simple estimate.


Document existing Visual Studio Project

I am a small business owner and my sole developer quit. Cold. I am not a coder. He developed an existing application that works .net, c#, javascript, sql, visual studio based, 250,000 lines of code. Needs to evolve to v2.0. I have zero documentation. Is there a product that can read the code and generate documentation that would significantly reduce the learning curve for my new development team? What is it? If not, suggestions?


quick approach to migrate classic asp project to asp.net

Recently we got a requirement for converting a classic asp project to asp.net. This one is really a very old project created around 2002/2003. It consists of around 50 asp pages. I found very little documentation for this project, FSD and design documents for only a few modules. Just giving a quick look into this project my head start to hurt. It is really a mess. I checked the records and found none of the developers who worked on this project work for the company anymore. My real pain is that this is an urgent requirement and I have to provide an estimated deadline to my supervisor. I found a similar question classic-asp-to-asp-net, but I need some more insight on how to convert this classic asp project to asp.net in the quickest possible way.