45

TL;DR Assumption ("contract") of spurious wakeups is a sensible architectural decision made to allow for realistically robust implementations of thread sheduler. "Performance considerations" are irrelevant here, these are just misunderstanding that became widespread because of having stated in a published authoritative reference. (authoritative references ...


10

I'd recommend making it more stable. Users are the canonical source of what your software does. If they want it, and have come to rely on it, I'd think twice about yanking it. A good example of this is the "Skiing" mechanic in the video game "Tribes". Originally a bug in how the physics engine handled jumping on a hill, it ended up one of the core game ...


8

Since the bug is in a library, here is another approach that you can take: Make a clone of the erroneous library function. In many cases people just append a 2 to the function name in these cases, but, if you have other changes that you would like to apply to the interface of that function, you might also give it a completely different name. Fix the bug in ...


8

Based on my experience writing compilers and related tools in C and similar languages, I would NOT choose to write a compiler in C if I had any other, better choices. And in 2016, there are plenty of better choices. But, it's your compiler, and YMMV. The TL;DR backstory: "We should forget about small efficiencies, say about 97% of the time: ...


7

Ignoring features in such a case does not make sense to me. The typical reason for using Python for prototyping is exactly because you can implement things in a fraction of time and "space" (=lines of code) than in C - by making use of features Python has, but C does not. If you would restrict yourself only to Python features which have a 1:1 correspondence ...


7

I'm guessing that if a large percentage of users expected it as a feature, it should be left "unfixed" or "fixed" to be more stable? Does the bug add value? If so, it's more of a feature. Sometimes a "bug" can end up as a value-add "feature." It's hard to really answer this conclusively because every single situation will be different. In this specific ...


7

Feature creep The phrase feature creep dates to at least 1990, as used in a comp.sys.mac Usenet post on the San Francisco MacWorld Expo of April 15, 1990: As an industry 'matures' everyone starts to look the same and the shows get less interesting, fewer and fewer really wonderfully new and striking products (I think it's because all the ...


7

If there are usability issues with the current software, then the argument is an easy one. If a significant part of your target users can not complete key tasks or take more time or energy than expected, then you should probably fix that before adding more features. Only a usability test can reveal such issues. Without objective data you will just get ...


6

It depends on your point of view. Here are a couple articles that discuss the topic. Developers see bugs as a mistake they made when translating requirements into code. Users also see deficiencies in the requirements as bugs. Developers get defensive when you say they made a coding mistake when really the mistake was a missing requirement, even if they'...


6

Before I say anything else, I want to say this - don't waste too much time trying to adhere to a best practice or a prescribed format. Instead, just do whatever lets you capture the requirements and move on. "Individuals and interactions over processes and tools", remember? That said, a user story that specifies who/what/why is geared towards enterprisy ...


5

The Proxy design pattern may be an interesting starting point. One of the variations described in Design Patterns: Elements of Reusable Object-Oriented Software is called the protection proxy, which is designed for access control when different objects should have different access rights. The Decorator pattern may also be interesting, especially since a "...


5

If I had a dollar for every time I heard "It will be dropped in X months, don't bother"..... But in your case you are the person who decides how long to maintain the version and how much work to put into it. Have you got lots of paying customers on 0.6 who will not bother to upgrade? Does it cost you lots of money to spend time on the old version? What ...


4

Create just one application which has on/off switches for various features. Developing and maintaining one application is much easier than doing the same with two apps. You can think that it won't be a big problem since two applications will be very similar, so there will be a lot of code reuse and as a benefit you'll get two applications, each will be ...


4

dpkg / APT has supported this for ages. There are two mechanisms for this. One is alternate dependencies by simply declaring the dependency like this: Depends: jquery | zeptojs You will declare that the package depends on either jquery or zepto.js. The other mechanism is Virtual Packages. A package can declare that it Provides a virtual package and then ...


4

In this specific case, it's a bug in an API of an internally-used library that other developers use. If those other developers thought the behaviour to be a feature, it is likely they have used it and have build working software upon it. Fixing the bug will probably break their existing code, and they will blame you for this. This makes fixing the bug a ...


4

It depends what kind of issues you are facing. "Fixing the environment" is somewhat vague, and lack of precision in describing the problem might in itself be a reason it is hard to get solved. If the problem is unclear it is also unclear who is responsible for fixing it. You have to break the perceived problems into concretely described issues with steps-...


4

In my past experience, I usually use the lowest level enabled in production environment (INFO?). Then, prefix log msg with keyword tag, say DEPRECATED. In log monitor/alert tool (can't suggest any tool, as I only experienced with in-house tool), specify the keyword tag as match condition. I try not use WARNING because those log messages could distract my ...


4

If feature C depends on features A and B in the sense that both should be implemented, verified and correct for C to work correctly, then the canonical way is to delay development of C until the feature branches of both A and B have been merged back to develop (or master, depending on what your main development branch is) and only create the feature branch ...


3

Any Turing-Complete language feature can be implemented in any other Turing-Complete language. Were that not the case, we'd still be stuck with the first programming language ever invented. So really, it comes down to how much effort you want to expend. In a way, you're asking the wrong question. The question is not "Should I implement a feature in the ...


3

For a PM, "Function" is purpose and "Feature" is a product behavior that a user can interact with. However people often get the two backwards (which I think is the case in your question). Getting me from place A to place B is a key function of a car. Its the reason (purpose) it exists. The steering wheel is a feature, as is the gear stick. The driver ...


3

It isn't worth fixing since caller code should use the same treatment (checking the condition) anyway, in order to deal with race condition. One treatment for two issues, which I summarize by the following: Spurious wakeup: waiting thread is scheduled before condition has been established. Forced oversleep: waiting thread is scheduled after condition has ...


3

1.Organize the permissions and their control Indeed, if you define individual feature access permissions, you will have, as in feature toggles, an if-clause in each feature to check if the user has the right permission. If you abstract the feature from the permission, for example by using a level of indirection, such as a feature group (e.g. one feature ...


3

I don't know Julia enough to know if the following can be applied to your situation in full, but to give you a general answer for comparable situations: IMHO it is a good idea to avoid maintaining two different code bases of the same package over several months. If the majority of your users is still using Julia 0.6, and you expect them to do so over a ...


3

It sounds like you are looking for BDD, and the Gherkin specification language. The gherkin language is a way to express business scenarios that can then be used to stub out code-level tests. Once you have your test stubs, you can start implementing the solution using more traditional TDD red/green/refactor style methods. Here’s a blog post on it: https://...


3

Hm. I look at your three scenarios and I see a dependency that worries me: scenario 1 seems to assume that you've already delivered scenario 2. When this happens to me, I look for alternative ways to split the story. At a minimum, this leads me to ask, "What's really different about these three scenarios?" Maybe nothing. Maybe I only need one scenario. Or ...


3

Merging two features If you merge feature branch B into feature branch A, then A contains both the features of A and B. That's what merging is, after all. This means that you no longer have two separate feature branches with individual lifecycles. When A gets merged into master, that also entails B's features (which are now in A) being merged into master. ...


2

How do you decide? You ask your users. Everything we do in developing software should be about meeting the needs of the users. You shouldn't redesign just for the sake of redesign, and you shouldn't add features that the users don't need. So, when faced with the opportunity to either add more features or improve the design, the first question you should ...


2

I would say this depends on what you call a "development feature". Unit tests or other automatic tests could be called "development features". Testing them separately does not make sense. In fact, you "test" them every time you run them. "Debugging tools" - maybe, if they are important to your team and you think someone could accidentally break them. ...


2

There are a lot of different ways to do permissions, but here are some pointers. Bear in mind there are two programs here: the administrator interface, which lets an admin set up users, groups, and permissions; and the main program, which needs to know who has which permissions. Start with the main program Permissions get set up only occasionally. But ...


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