Hot answers tagged

27

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 ...


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


15

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 ...


15

There are five ways to handle this: expand capacity renegotiate resign go down valiantly drop quality 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 ...


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

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

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

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 ...


9

About the terminology: A requirement expresses a need or a constraint that the system has to fulfil, in principle independently of the solution that will be chosen. Examples: "The system shall allow only valid contract types to be entered", "The system shall facilitate the analysis of contractual trends". A feature is about something ...


8

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 ...


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 ...


8

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 ...


7

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 ...


7

How do other companies process such requirements? Differently. Different businesses have different processes because they have different needs, different risk tolerance, different resources... I'm wondering why, the business cannot just drop the requirements to developers Often, because it's difficult/impossible/expensive to find developers that are ...


7

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 ...


7

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 ...


7

The environments of Development, Test, Acceptance and Production evolved out of necessity, pragmatism and convenience. In other words, they exist because they make sense. The origin of these environments is the Software Development Life Cycle. The three environments correspond roughly to the Development, Integration and test, and Operations and ...


7

First off I think we have to say that this is not an uncommon thing to happen. Requirement gathering is hard and customers often expect programmers to 'fill in the gaps' from broad requirements. From an agile point of view its not a problem at all. Simply add more requirements to the backlog and proceed as normal. If you have agreed a fixed price or ...


7

When a typical software product grows in size over years, there will be definitely more places where bugs can hide, and occasions where more complex, unforeseen interactions can happen - this is where your boss is right. On the other hand, countermeasures against degrading quality involve often even more code in form of automated tests, automated ...


7

1) You Ain't Perfect Even if you had a great upfront design handed to you by some sacred initiate of the divine architectural order. You are probably going to make a mistake. Now you could write out all of the code upfront, exactly to specification, and then press the compile and run button. But it probably won't compile. You have probably made 3-4 mistakes ...


6

TL;DR Your experience is typical. As noted in other answers the Agile Manifesto, eXtreme Programming (XP), Scrum, Kanban, Lean and many other techniques are popular to avoid the inefficiencies you point out. Your question is slightly controversial is it asks "why is a SDLC so inefficient". Yet not all SDLCs are this inefficient. You can have a ...


6

“All software has an expiration date by which time it must be rewritten from scratch.” That is true only for improperly designed and implemented software. For properly designed software it is true that: "All sofware is completely replaced every so often." But this is same as "Cells in human body are completely replaced every 7-10 years". That doesn't ...


6

You have an incorrect assumption in there. Duck typing can be statically checked. Since the compiler knows what type is being passed into the function and it knows what operations that function needs, it can detect errors when there is a mismatch. Likewise, your second bullet is a little optimistic. Languages like Java have type casting, meaning you can get ...


6

1. Much of what you said is just as true in statically-typed languages. Duck-typing on the other hand does not care about the explicit type of an object - as long as the object has the relevant attributes (data members and functions), the program can go ahead. If the object has a function with the same name as what is required by some piece of code, then ...


6

If I understand your question, you're interested in SDLC that were before the emergence of the Agile, i.e. not only the agile manifesto 2001, but also the agile methods that were promoted individually by the authors of the manifesto (e.g. XP, Crystal, etc...). SDLC time travelling Before Agile, in late 90's, the most popular SDLC was probably the Unified ...


5

Frankly, I think you should look at them all. Scrum because it heavily emphasizes iterative and incremental development. XP because it gives a lot of advice on the technical side of development. Kanban because it emphasizes WIP limits and flow. That's how I've come to know them anyway; I've noticed they've all influenced each other heavily over the years. ...


5

If you are finding it hard to get code reviews to happen in the time you currently have before QA, you should consider making code reviews more lightweight, as Code Review in Agile Teams, Part II that @Dukeling posted discusses. I found that even the simplest thing that could possibly be called a code review gave benefits: before committing code (or pushing ...


5

It is your responsibility to gather enough information to make it reasonably possible to write an application that substantially fulfills the client's expectations. Usually that means going back to the client, asking the right questions and getting clear answers. There are plenty of resources that will teach you how to gather useful requirement ...


5

"The BA is responsible for clarifying the requirements for the team" It is the responsibility of the scrum master to seek clarification from the BA outside the daily standup meetings. It makes sense to include BA in the planning meetings of individual sprints but not in daily standup meetings. I don't understand how the analogy to chickens and pigs applies ...


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