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
Remember: These are guidelines, and that as such are meant to
adopted, adapted, or dropped based on circumstances.
Beware: Dumping all this ...
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 ...
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, ...
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 ...
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 ...
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 ...
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 ...
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 ...
There are five ways to handle this:
go down valiantly
As you are already behind the ball, you have no time to invest into increasing your overall capacity. But if you did:
Expanding the team requires sacrificing one or more active developers to teaching and training. There is also an upper-bound on team size ...
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,...
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 ...
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 ...
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 ...
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 ...
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 ...
Battery life - many applications running in the background will drain your battery really fast.
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
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:
versus this, courtesy of 99 Bottles of Beer:
for i=99 down to 1
j = (i+constant);
if (i=1) ...
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. ...
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-...
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 ...
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). ...
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 ...
It all depends on a lot of factors that you did not share with us. First, how did you determine that you will be late and by how much:
How close to the deadline are you?
How well defined is the work left to do?
How reliable is your effort estimate for the unfinished work?
If you determine that you can finish in time with a moderate speedup (10-15%), you ...
I think first of all you have to clear your situation. What do they want from you?
It is very unlikely that they want you to learn an ancient language, because this now seems a dead end: there is a decreasing chance to find anyone knowing or wanting to learn G2, so the knowledge will be buried in the collapsing heap of code when the current scientists leave ...
What type of code are you talking about?
There are many security tools used in the process of hacking, including scanners like nmap, sqlmap, Nessus and many others. I would imagine they have the same type of software life-cycles like any other applications.
On the other hand, there are exploit codes. Codes written to take advantage of a very specific ...
The full context is probably "promote a file to production" or something like that. It just means that the file is to be moved to the "more important" or "more critical" system. Presumably this only happens after code-review, testing, Q&A sign-off and so forth.
Analogy: a team leader is "promoted" to a manager.
How is a file moved from one ...
If you are going to review the code at some point, it's no more expensive to do the review early. And it seems you have an expensive testing process, so you don't want to test twice. Therefore it is cheaper to review the code before testing. Reviewing the code after testing doesn't make the work go faster. It makes it go slower and tempts you to deliver ...
It is a life cycle of the software, not of the vendor.
SDLC is not called Vendor Life Cycle. No matter if vendor leaves or not, software is assumed to work and this phase is its maintenance.
Note how Wikipedia definiton abstains of vendor related things and focuses on software:
Software maintenance in software engineering is the modification of a ...
It depends on what you actually call "Build", especially when you say "Continuous Build".
If one defines "Build" in the narrow sense of compiling some source code into a binary executable, then you are right, such a "Build" step does not make sense for an interpreted language like PHP. However, for some people a "Build" step is defined by everything which ...