Tag Info

Hot answers tagged

92

The sound-bite answer is that requirements are what your program should do, the specifications are how you plan to do it. Another way to look at it is that the requirements represent the application from the perspective of the user, or the business as a whole. The specification represents the application from the perspective of the technical team. ...


83

Specification says UNIQUE HTML 4.01 specification says ID must be document-wide unique. HTML 5 specification says the same thing but in other words. It says that ID must be unique in its home subtree which is basically the document if we read the definition of it. Avoid duplication But since HTML renderers are very forgiving when it comes to HTML ...


43

I'm the maintainer of Python's runpy module, and one of the maintainers of the current import system. While our import system is impressively flexible, I'd advise against adopting it wholesale without making a few tweaks - due to backwards compatibility concerns, there are bunch of things that are more awkward than they would otherwise need to be. One thing ...


40

I think you've done your part by pointing out the problem and suggesting an alternative. If they insist that you do things that expose them to a certain level of risk, you should make sure you have a paper trail (and back-ups of it) showing that they explicitly requested this, knowing the risks involved. If you're really concerned, you could tell them that ...


35

How can you know you're done, if you don't know what it's supposed to look like when it's done? Feature creep will catch you. You'll be trying to deliver for a client, and, as completion time rolls around, they're going to discover 10,000 little things that they absolutely have to have. In order to get paid, in order to get your boss off your back when the ...


32

Exception specs are bad because they're weakly enforced, and therefore don't actually accomplish much, and they're also bad because they force the run-time to check for unexpected exceptions so that they can terminate(), instead of invoking UB, this can waste a significant amount of performance. So in summary, exception specs aren't enforced strongly enough ...


30

Requirements document what is needed - they shouldn't specify the how, but the what. Specifications document how to achieve the requirements - they should specify the how. In many places these documents are not separate and are used interchangeably.


27

if you want to be just a programmer, then you wait until someone else has figured out what the client needs and then code that if you want to be a developer, and this is your client, then you take your client's hand and gently walk them through the dense scary forest of possibilities until together you find the happy bunny-filled meadow at the intersection ...


26

Next to ncoghlan I'm the other maintainer of Python's import system and the author of its current implementation, importlib (http://docs.python.org/dev/py3k/library/importlib.html). Everything Nick said I agree with, so I just want to add some extra info. First, don't rely too heavily on PEP 302 directly but instead look at what importlib provides in terms ...


25

First of all, as others have said, there's a difference between software actually working versus software being sold with a legal guarantee that it works. The disclaimer text you cite means that the original licensor you got the software from does not grant any kind of warranty. You can offer the software yourself with a warranty attached. The original ...


24

Heap pollution simply implies that you have "bad stuff" in your heap. It is an analogy to (for example) water pollution which is where you have "bad stuff" in the water. Specifically, the bad stuff here is objects of type A where you ought to have objects of type B ... according to the static typing. Some hole in the static typing is allowing the bad ...


22

I think the Joel test is up to date - it's as up to date as much of the other software writing that's "timeless". Doing product development (which includes software development) without a spec is just madness. How do you know where you want to go? There's only one point I'll make about writing a spec (I don't actually think Joel's specs are very good... ...


20

As a consultant, I understand one simple rule of consulting: You can't help people that don't want to be helped. You can't make anyone do anything they don't want to do except by force of authority, which you don't have. As a coach, I introduce Agile with three rules: It is impossible to gather all the requirements at the beginning of the project. ...


19

Some other things you may need are: Usecases or Workflow descriptions: Just because you know what a screen looks like, do you know how bad input is handled? Do you know how to transition between screens in ALL cases? You could include error handling here as well. High-level system description: Something the explains what the whole system that these 25 ...


18

You asked "how bad". So to flesh out @RobertKoritnik's (entirely accurate) answer a bit... That code is incorrect. Incorrect doesn't come in shades of grey. This code violates the standard and is therefore incorrect. It would fail validation checking, and it should. That said, no browser currently on the market would complain about it, or have any problem ...


17

I use the Cone of Uncertainty Say in a loud booming voice Basically you do the best estimate you can give the information you have. But you also point out that given the vagueness in the specifications that there is a high uncertainty on these estimates (Point management at the site so they can read up on the principle). As you progress towards the target ...


17

What you suggest is fine from the point of view of the Systems Engineering purists. (There will be a few Agile devotees who think its all way overt the top... and you should just get out and do stuff with the usual reviews, etc). However, you need to take into account what you are doing, and who you are doing it for. Doing a project for yourself is ...


17

I see two good possible approaches to to this problem. However, it's important to realize two things. First, requirements engineering is hard work - turning an idea into a formal specification that is enough to build a system takes a lot of time, effort, and practice. Second, if you have good requirements (in any format, from a formal specification to less ...


17

Your situation is quite common and when I was developing things for non-technical clients it happened to me all the time. When those people hire you they most often don't know what they really want. They just know they want "something like that" or "something that can help me with this". Part of a job of a competent software developer is to help those ...


15

By estimating how much money/time it will cost to do those hundreds of features with high quality. Very, very few clients will put their money where their mouth is.


13

Did you read part 2 of the article or his sample specification? They embody a couple important principles when writing a specification. Don't overdesign. The purpose of writing the spec is to force you to think about important things like what happens when there's an error, and how you expect the user to interact with the system. You don't have to go ...


12

When you have the privilege of starting on a new project you have a blank canvas--which is both exciting and daunting at the same time. I work in iterations, and this is how I divide up the work: Start with the goals for the project. Goals are necessarily the most vague, but helps you focus on what the client or user intends to do with the software. At ...


12

Requirements: Determine the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders. Specifications: They provide a precise idea of the problem to be solved so that they can efficiently design the system and estimate the cost of design alternatives. They ...


12

It means that value types are stored directly where you define them, which makes them more efficient when compared with reference types. What exactly does that mean? If you have a local variable of a value type it will be usually stored directly on the stack (but there are many exceptions). If you have a field of a value type, it will be stored directly in ...


12

I'd categorize those as "implicit" requirements. Like "User must be able to log in" implies that there is the notion of a User (with an associated database table/store of some sort), some notion of a password or other credentials, and the requirement to store the user ID or some other token in the session. This further implied (to me, anyway) that there ...


11

With hard disk space at pennies per gigabyte per month, there's no good reason not to put documents in the source control system, and it is likely to be useful. My personal preference is to write documents using inline markup, e.g. Wiki Markup or DocBook. This allows use of powerful tools for document comparison and revision.


11

You can't "make" a manager understand agile any differently than you can make a developer understand it. You need to present him with the arguments (the books of Kent Beck are a good start) and let him make up his own mind. Alternatively, you can ask him to let you run an experiment. Take a small project and run it with iterative development and keep close ...


11

A specification nearly always changes during development for any but the most simple of projects. The reasons are: Development or more likely integration testing of the project uncovers things not noticed when original spec was done - from edge cases to major facets. E.g. developer notices that out-of-order message confirmations might arrive. Real world ...


11

This interview with Anders Hejlsberg is quite famous. In it, he explains why the C# design team discarded checked exceptions in the first place. In a nutshell, there are two major reasons: versionability and scalability. I know the OP is focusing on C++ whereas Hejlsberg is discussing C#, but the points that Hejlsberg makes are perfectly applicable to C++ ...


10

If your boss has specifically said not to do X, then don't do X. I go crazy at work with down time unless I find something constructive to do. That's an opportunity. Learn something new, but don't disobey a direct order because you don't want to be bored.



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