Hot answers tagged

466

Foreword This is a daunting task indeed, and there's a lot of ground to cover. So I'm humbly suggesting this as somewhat comprehensive guide for your team, with pointers to appropriate tools and educational material. Remember: These are guidelines, and that as such are meant to adopted, adapted, or dropped based on circumstances. Beware: Dumping all this ...


101

The very first step would be introduction of a Version Control System (SVN, Git, Mercurial, TFS, etc.). This is must to have for a project that will have re-factoring. Edit: regarding VSC - Every source control package can manage binaries, although with some limitations. Most of the tools in the market has the ability to use a custom difference viewer and ...


43

When I have to work with spaghetti code, the first thing I work on is modularization. Find places where you can draw lines and extract (more or less) independent pieces of the codebase. They probably won't be very small, due to a high degree of interconnectedness and coupling, but some module lines will emerge if you look for them. Once you have modules, ...


25

How to document code? You already have a hint: look at how Java API is documented. More generally, there is no unique set of rules which apply to every project. When I work on business-critical large-scale projects, the documentation has nothing to do with the one I would write for a small open source library, which, in turn, has nothing to do with the ...


22

I don't know if this is an option to you, but I would start trying to convincing them to hire more professional developers. This way they could concentrate in domain problems (I'm sure they have enough there). I believe they are very smart people, but becoming a good developer demands a lot of time. Are they ready to spend so much time in a activity that ...


20

Wow. Sounds like you have a really big challenge ahead of you! I'd do something along the following lines: First of all: Prioritize. What do you want to achieve first? What is the most important for the current state of the project? What will you get the most from vs how much time it'll take to get there. Ensure that you have a version control system. Git ...


20

Here's an influential programmer's opinion on the subject : "the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch."[1] -- Joel Spolsky


17

For most users the primary function of a smart phone is as a phone, followed by receiving text messages, and receiving e-mails. The designers of a smart phone OS must ensure that no application can interfere with these primary functions. The other constraint of mobile is battery life, any app which "spins" in the background it will consume current and ...


14

In a well set up software development shop you will have various separated environments. "Sandbox", "development", "integration test", "User Acceptance Test", "Performance Test" and finally "Production" (or "beta" and "General Release" if you are selling/distributing software). This should be a progression of quality and rigorousness of testing. From "gee ...


14

Consider just how many things can change over a short timescale: New OSs appear. Existing OSs get rebuilt. 3rd party packages appear, develop, drop off support or go obsolete. New hardware appears, including completely new devices and paradigms (eg. touch-screens becoming the norm). Existing paradigms are exposed as having exploitable flaws and are abandoned,...


13

In my experience, the distinction you are making between "in house" and "distributable product" is false. There are companies that take their software development process seriously and those that don't. Whether they are "in house" or "bespoke" or "shrink wrap" tends to not come into it as much (though if they are "shrink wrap" providers, if they don't have ...


13

There are three questions asked of every participant at a standup meeting. They are: What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal? Notice that "requirements ...


11

Traditional (and incorrect) waterfall is a single iteration through the phases of the lifecycle. First, you perform requirements engineering. Using those requirements, you architect and design the system and verify/validate those designs. Then, you implement the system. Once the system is implemented, you test it to ensure it works as intended. Finally, you ...


11

For most real life situations agile stops at delivery to QA/UAT or whatever its called. The effort to move from QA to Production in a real life environment is often underestimated. In many cases this involves real business users in testing, management sign off from the real line of business managers, scheduling the release with operations etc. etc. This is ...


11

I used to work for a company that had source code that had "copyright 1984" at the top of the file. It was still in the codebase because it worked, and it hadn't been removed or replaced because it still worked. There's a lot that does get rewritten eventually, but its so rare that it might as well be never. eg. TCP/IP is still with us even though we're ...


11

I don't see what is fishy about the process you describe. If you have iterative development with short release cycles (even if it is just internal releases) and continuous product-owner feedback and reevaluation of plans based on the knowledge gained by each release, I would say you are agile. The benefit of iterative development have been known for a long ...


10

You may read this article http://www.joelonsoftware.com/items/2007/12/04.html of Joel Spolsky, which is exactly dealing with your question. I am in a position where I had to work on both the last years - a medium-sized software product beeing sold, and some in-house software. From that experience, I can tell you there are differences between those two ...


10

They say that the first step in solving a problem is admitting that you have one. With that in mind, you might start by generating a dependency graph that illustrates the vast tangle that is your current code base. Good tool to generate dependency diagram? is a few years old but contains some pointers to tools that can help create such graphs. I'd go with ...


9

Practices and SDLC within the industry vary wildly from company to company (or even from team to team within the same company). From your description it sounds like the SDLC as taught in your university is a more formal, heavyweight, non-agile process. There are lots of projects following such processes (using differing terminology, tools and artifacts, e.g. ...


9

Two books that best meet your needs are probably: Ian Sommerville's Software Enginering Roger Pressman's Software Engineering: A Practitioner's Approach I own and have read the 8th edition of Sommerville's book. I honestly think that it might be the best for you. The university that I graduated from recently switched to the Pressman book, but I'm not as ...


9

Battery life - many applications running in the background will drain your battery really fast. Available memory Processor Small screen Did I mention Battery life? :) Here is an article about this feature on the Windows Phone Platform. It starts by explaining the reason why this it is a "necessary evil": Mobile Matters - Windows Phone 7 Tombstoning A ...


9

After looking into Gensym G2 for a bit it looks like the way to approach this problem is going to be highly dependent upon how much of the code base looks like this: or this: versus this, courtesy of 99 Bottles of Beer: beer-bottles() i:integer =99; j:integer; constant:integer =-1; begin for i=99 down to 1 do j = (i+constant); if (i=1) ...


9

Usually the complaints you hear upfront has nothing to do with the important problems. After all, it is entirely normal to hear of these complaints in any software projects. Hard to understand code? Check. Massive code base? Check. The real problem is that people leave, and when the new person joins the organisation, there is a typical disorientation. ...


9

Questions like these are the whole reason the Software Carpentry project exists. For the last 14 years, we've been teaching scientists and engineers basic software development skills: version control, testing, how to modularize code, and so on. All our materials are freely available under a Creative Commons license, and we run a couple of dozen free two-...


9

We understand QA as an extra bit of verification to a certain build (release candidate) before this build gets deployed to the customer. There is nothing inherently incompatible between this form of QA and iteration-based methodologies like Scrum. Within Scrum, the team delivers a deliverable on an X-weekly cycle it its customer. The important part here is ...


8

If your company actually uses SCRUM, then the project has a SCRUM Master whose main job it is to remove any obstacles the team members see in their progress. If you believe the lack of a database hinders your work, discuss it with the SCRUM Master. I see three possibilities: As a new team member, you're unused to the way things are done in this company. ...


8

Scrum is all about iterative releases, showing the user what they are getting before they get it, letting them prioritise the goals. This is perfect when your deadline is tight and the project seems directionless. It means that the customer can see the constant development (rather than it being a black box which churns out a useless product just before the ...


8

Testers don't want to re-test is kind of like saying "coders don't want to refactor." Its part of the job. The process can be restated as something like this: Tasks are created. Code is generated. Code is tested. Code is reviewed. Imperfections are found in the code. New Tasks are created to address these imperfections (e.g. the code is refactored). ...


8

One common way to handle this scenario is to use a trunk/branch concept. What you do is have the single repository and branch the 5.x.x version for maintenance reasons. Then you put all of the your new 6.x.x changes into the trunk. That way you maintain all of the version history of your code. This also allows you to check out the old version and make a ...


7

Just because you are working alone doesn't mean you may neglect proper engineering techniques, as you seem to have already experienced for yourself. There is absolutely no way that you can avoid thinking and documenting a proper architecture and design for your components (considering anything but a trivial component). You will have to face changes, your ...


Only top voted, non community-wiki answers of a minimum length are eligible