答: Ladislav nails it above in re culture, but have you checked out JIRA & Greenhopper from Atlassian? We have no interest in agile here, but I did evaluate it and found it to be a reasonably priced, easy to use and suitable digital approximation of stickies on a whiteboard. And it's web-based.</p>

Title: What electronic user-story-mapping tools can you recommend?

Body:
Agile software development relies heavily on a work item type called user stories.  For example, you have a backlog full of user stories and you can select a few of them to work on during the next sprint.

But where and how do you find user stories to put into the backlog?  There is a popular technique for doing that called story mapping.  Jeff Patton invented it and here is the definitive guide on how to do it.

The question is, what electronic tools are out there that support Patton's story-mapping technique?

I've done a bit of research, found Pivotal and Rally plug-ins (but I'm not a customer of either) and I'm currently experimenting with SilverStories.

What other tools are out there?  What have you used?  What do you (not) recommend?  Why?

UPDATE: Some people who wrote comments seem to lean towards an answer that applying this technique is simply impossible with an electronic tool and we should just accept that.  Can't someone write it up as an answer?

UPDATE (to clarify the question in light of Alex Feinman's comment): the question is about identifying options for story-mapping.  Since Jeff Patton's technique can obviously be done on a white-board with stickies, the question focuses on additional options that might be provided with electronic tools.  (Premature) commitment to any particular tool or class of tools is not the point of this question.


问:
Is it unusual for a small company (15 developers) not to use managed source/version control?
It's not really a technical question, but there are several other questions here about source control and best practice.

The company I work for (which will remain anonymous) uses a network share to host its source code and released code.  It's the responsibility of the developer or manager to manually move source code to the correct folder depending on whether it's been released and what version it is and stuff.  We have various spreadsheets dotted around where we record file names and versions and what's changed, and some teams also put details of different versions at the top of each file.  Each team (2-3 teams) seems to do this differently within the company.  As you can imagine, it's an organised mess - organised, because the "right people" know where their stuff is, but a mess because it's all different and it relies on people remembering what to do at any one time.  One good thing is that everything is backed up on a nightly basis and kept indefinitely, so if mistakes are made, snapshots can be recovered.

I've been trying to push for some kind of managed source control for a while, but I can't seem to get enough support for it within the company.  My main arguments are:

We're currently vulnerable; at any point someone could forget to do
one of the many release actions we have to do, which could mean whole
versions are not stored correctly.  It could take hours or even days
to piece a version back together if necessary

We're developing new features along with bug fixes, and often have to delay the release
of one or the other because some work has not been completed yet.  We also have to force
customers to take versions that include new features even if they just want a bug fix,
because there's only really one version we're all working on

We're experiencing problems with Visual Studio because multiple
developers are using the same projects at the same time (not the same
files, but it's still causing problems)

There are only 15 developers, but we all do stuff differently; wouldn't
it be better to have a standard company-wide approach we all have to
follow?

My questions are:

Is it normal for a group of this size not to have source control?

I have so far been given only vague reasons for not having source control - what
reasons would you suggest could be valid for not
implementing source control, given the information above?

Are there any more reasons for source control that I could add to my
arsenal?

I'm asking mainly to get a feel for why I have had so much resistance, so please answer honestly.

I'll give the answer to the person I believe has taken the most balanced approach and has answered all three questions.

Thanks in advance

答: Some people have trouble realizing how bad the status quo is until they see something better for themselves.  What you need is a good demo.  Show some actual examples of tasks it could improve.  "This took me 4 hours to track down with our current system, but this one source control command told me instantly."

OwnerDisplayName: LordScree

ContentLicense: CC BY-SA 3.0


问:
Should you write good documentation and clean code to increase the "Bus Factor"?
One of the main goals of software development companies is to increase their Bus factor This is also advocated in a talk that was organized by Google.

That means that you should code and document everything in a way that if you're run over by bus tomorrow, the project can still continue. In other words, you should make yourself easily replaceable by another programmer with a similar skill set to yours.

Being replacable, isn't that against the interest of a developer? In the book, 48 laws of power Rule 11 states that you should try to keep people dependent on you, in order to gain power, which then translates into monetary rewards.

Apart from the scenario, where you need some documentation for yourself in order to continue a project after 6 months of pause, there seems to be a clear conflict of interest here between the developer and the software company.

So as a programmer, should you really write excellent documentation and easily readable code for everyone; or should you write code and documentation in a way that it does the job and you yourself can understand it, but another person may have trouble understanding it?

答: I'm also going to point out that if you don't have occasion to look at that code very often, you too will have trouble figuring it out in six months if you obfuscate it deliberately.</p>


问:
Can anyone recommend a good robot kit for learning C++ robotics programming?
Preferably something that is a combination of affordable and close to real world robotics programming and will allow me to program it with C++.</p>

答:
The Robotic Operating System provides a fairly large amount of code for developing robots in C++. It includes a large number of libraries to help with development and exploration (for instance, it includes OpenCV and the Point Cloud Library for perception and modeling, sensor drivers, and more) for high performing algorithms without the difficult implementation. It also includes a list of robots that already support it.

The library is open source and freely available, and used in real world robotics projects around the world.


答:
If you want to get started without investing any money at all, there are several very realistic robot simulations. The PlayerStage Project for example simulates several real robots, so if your code works, you could switch to a real robot without too much changes.

There are more projects like this. PlayerStage can be used in C++, though I would think about using a language like Python for the higher level code.

Title: Can anyone recommend a good robot kit for learning C++ robotics programming?

Body: Preferably something that is a combination of affordable and close to real world robotics programming and will allow me to program it with C++.</p>


问:
How much does/should your style imply about your skill in a language?
Two things I've noticed in the past week that make me wonder:

An interview where my Perl skills were reviewed. I always use C-style for loops and use map about once in every 10,000 lines of code, so I almost always have to reference it before using it. While I can interpret others code using that, it's not my style and that is for reasons involving readability and ease of changing between languages. I at least perceived that I was dinged for that.

This answer to my question in which the answerer proceeded to refactor and bullet-proof my tiny script. I admit I was a little bit offended and kind of annoyed at that, though I can understand how that as a habit may be helpful.

I understand that in a team, my style will need to adapt what the team has decided is correct -- this is necessary in every project and everybody has their own ideas. Yet I feel like I'm judged for what is syntactically fine and readable code.

How much does the style of your smaller snippet code weigh in? Does code like that imply to others that I don't have control of the language because I didn't use all the features? Does my code imply that I'm not familiar with unit testing and proper testing because I didn't fully error-protect a tiny script?

答:
While I can interpret others code using that, it's not my style and
  that is for reasons involving readability and ease of changing between
  languages.

This seems odd to me. I find it much more difficult to switch between two similar languages than to switch between two that are very different. When two languages have a lot in common, there's a tendency to fit them both into a common mental model and you end up having to constantly remind yourself about all the differences.

I'm sure that anyone who uses both C and C++ has at some point let some C++ slip into their C code or forgotten to take advantage of useful language features in C++. You never have that problem when you switch between, say, C++ and Scheme, because the two languages aren't remotely alike.


问:
What electronic user-story-mapping tools can you recommend?
Agile software development relies heavily on a work item type called user stories.  For example, you have a backlog full of user stories and you can select a few of them to work on during the next sprint.

But where and how do you find user stories to put into the backlog?  There is a popular technique for doing that called story mapping.  Jeff Patton invented it and here is the definitive guide on how to do it.

The question is, what electronic tools are out there that support Patton's story-mapping technique?

I've done a bit of research, found Pivotal and Rally plug-ins (but I'm not a customer of either) and I'm currently experimenting with SilverStories.

What other tools are out there?  What have you used?  What do you (not) recommend?  Why?

UPDATE: Some people who wrote comments seem to lean towards an answer that applying this technique is simply impossible with an electronic tool and we should just accept that.  Can't someone write it up as an answer?

UPDATE (to clarify the question in light of Alex Feinman's comment): the question is about identifying options for story-mapping.  Since Jeff Patton's technique can obviously be done on a white-board with stickies, the question focuses on additional options that might be provided with electronic tools.  (Premature) commitment to any particular tool or class of tools is not the point of this question.

答:
Based on the information in the comments on this question, some of my own research, and existing suggestions of general Agile planning tools, it looks like there is no tool right now that is built with the Patton technique in mind.

Adapting another digital whiteboard/sticky notes tool and applying the mapping technique yourself is probably your best bet at this point.


答:
Now that DVCS tools like Git and Mercurial are available, and incredibly easy to set-up and use, there's really no excuse for even a team of 1(!) not to use source control. It's not about size of team, it's about having a commented history of your changes and the ability to support workflows such as fixing production issues whilst working on a new release, and tracking the state of the source code for different versions.

If I were offered a job in a team that had got to that size, and not one of the developers had suggested using a VCS, or if "management" had prevented them, I'd turn it down flat. It's just not an acceptable way of working these days.

Title: Is it unusual for a small company (15 developers) not to use managed source/version control?

Body:
It's not really a technical question, but there are several other questions here about source control and best practice.

The company I work for (which will remain anonymous) uses a network share to host its source code and released code.  It's the responsibility of the developer or manager to manually move source code to the correct folder depending on whether it's been released and what version it is and stuff.  We have various spreadsheets dotted around where we record file names and versions and what's changed, and some teams also put details of different versions at the top of each file.  Each team (2-3 teams) seems to do this differently within the company.  As you can imagine, it's an organised mess - organised, because the "right people" know where their stuff is, but a mess because it's all different and it relies on people remembering what to do at any one time.  One good thing is that everything is backed up on a nightly basis and kept indefinitely, so if mistakes are made, snapshots can be recovered.

I've been trying to push for some kind of managed source control for a while, but I can't seem to get enough support for it within the company.  My main arguments are:

We're currently vulnerable; at any point someone could forget to do
one of the many release actions we have to do, which could mean whole
versions are not stored correctly.  It could take hours or even days
to piece a version back together if necessary

We're developing new features along with bug fixes, and often have to delay the release
of one or the other because some work has not been completed yet.  We also have to force
customers to take versions that include new features even if they just want a bug fix,
because there's only really one version we're all working on

We're experiencing problems with Visual Studio because multiple
developers are using the same projects at the same time (not the same
files, but it's still causing problems)

There are only 15 developers, but we all do stuff differently; wouldn't
it be better to have a standard company-wide approach we all have to
follow?

My questions are:

Is it normal for a group of this size not to have source control?

I have so far been given only vague reasons for not having source control - what
reasons would you suggest could be valid for not
implementing source control, given the information above?

Are there any more reasons for source control that I could add to my
arsenal?

I'm asking mainly to get a feel for why I have had so much resistance, so please answer honestly.

I'll give the answer to the person I believe has taken the most balanced approach and has answered all three questions.

Thanks in advance


答: You should get yourself a GIT version control immediately. You can use it even from Google Code Project Hosting. When the others see you commiting changes in just a click while they manually copy things, perhaps they change their mind about it.</p>


问:
Which programming methodology would be a good fit for us?
Unfortunately, somebody has taught our upper management the word "Agile" and now they want us to move towards it. I have a peripheral understanding of agile (in principle) but have never used it in practice. From what I know, it will not be a good fit for our organization. Right now, things are pretty grungey. Here's how it is;

We're a very small team - two developers, one DBA, one designer. The company I work for makes a disproportionately large amount of money relative to its size, and nearly 95% of that is pure online sales.

From a development perspective, we are subjected to many desk invasions during a typical day (we're tech support as well as dev), work can regularly just fall out of the sky at a moments notice if a sales team member promises something to someone. We do undertake larger projects too, and they're a nightmare with the constant interruptions. Some of us are starting to tear our hair out! Project plans are drawn up by non technical managers in excel spreadsheets, where they try and break the task down into bite-sized sentences that they can understand and put a date beside each one. These dates are always hideously unrealistic and often missed, and our meetings (which we have around weekly) are regularly filled with awkward moments with people asking "why hasn't this been done yet".

I am pretty sure Agile isn't the one for us. Now, given that (and i have tried) this company will not change its ways, and only the dev team is willing to change, is there a development methodology that we could adopt which is a good fit for just saving us some sanity?

答:
Agile was actually designed to address many of the exact problems you are having.  If management has truly bought in and won't pervert the process, you could see a big improvement.  Let me address your issues point by point.  My experience is with scrum, so I'll talk from that point of view, but I'm sure other implementations have similar benefits.

work falling out of the sky These stories get put on the bottom of the backlog until the product owner and team can meet to agree to move it up.  Its priority gets determined relative to all your team's other commitments, and that priority is visible to every stakeholder who is interested to look.  It should be extremely rare to add a new feature in the middle of a sprint, and only the highest priority bugs should be allowed to interrupt a sprint.  It's amazing how many "emergencies" can wait until the end of next week when that is made a regular expectation.

undertaking larger projects You will have the visibility to show how short-term priorities impact your long-term projects.  If people continually move user stories in front of your long-term projects that's okay, but in order to make that decision everyone will know the impact it will have on the long-term project's schedule.

project plans are drawn up by non technical managers User stories are supposed to be written from a non-technical point of view, but your scrum team should be empowered to make estimates and determine implementation details.

dates are hideously unrealistic Your team handles all the estimates, because you are the ones who know what you're doing.  If those estimates aren't acceptable to the business, they must decide how to prioritize the features.  If they need more work than you can handle, the need to hire more people will be clearly visible.

dates are often missed  First, your estimates will be more realistic, which should help.  Also, you're biting off smaller chunks and actually finishing them, which helps the business feel like you have produced something useful even if not feature complete.

meetings filled with awkward moments  Agile has more visibility and a much quicker feedback cycle, with a product owner heavily involved.  Your blocking issues and reasons for delay should not be a surprise.

also doing tech support  Contrary to popular belief, agile is not incompatible with a divided schedule.  Scrum factors in your interruptions into your team's velocity.  If you normally spend half of your time doing tech support, you will simply have half the velocity.

What mangement and sales must realize is that agile isn't a way to exercise tighter control over the development  team, it gives the team more autonomy to do what they're good at while helping the business realistically consider all its priorities whenever assigning work to the team.


答:
Reasons to support not using version control are fairly limited.  All that I can think of is the technical aspect of things.

There is too much of a learning curve to convert your entire staff's workflow to incorporate a versioning system to be cost effective.

Your project manager does not feel that it would be beneficial to introduce the overhead into the workflow of managing and maintaining a repository.  (Primarily an issue with older Versioning Systems)

There are many reasons to use a versioning system.  At the very least stop moving things around.  Work  with patches.  Versioning systems can do exactly what it is that you say you do.

You can work on the next version at the same time you are doing bug fixes and release them separately.

Instead of moving files from one location to another to work on it you can create a branch and merge it into the master upon completion.

Each developer can have their own copy of the source code to prevent the issues with the same project open on multiple machines.

Accidents happen, if the code becomes severely broken all you need to do rollback to the last working revision number.

Version control works well paired with bug trackers and continous integration systems.

I personally as a one person team use versioning, bug tracking, continous integration, code review, code consistency checking, unit testing, selenium tests, source code analysis, and there may be more I'm forgetting.  I admit, there is a slight learning curve.  There's also a tradeoff of additional administration time necessary to the addtional steps you automate.  In my experience, the effort saved outweighs the additional administration time.


问:
How should we implement Scrum with two projects for one team?
I'm starting at this new company as a scrum master, and they want to dive into Scrum, which is nice and all, but they only have enough people (4) for one team.

The road map includes delivering a new product and maintaining the old one, so what should we do?

2 products backlogs for 1 team? How should we do planning in this case?

1 product backlog for 2 products? How will sprint review work in this case?

答:
With the same people working on both projects your choices are limited:

Lump all the stories into one pot and work on them in each sprint. The big drawback with this is that no one will want to work on the stories for the old project.

Split your time so you work 3 days a week on the new project and 2 days on the old (for example). This will require you to have two sets of planning meetings etc. The daily scrum meetings for each day will not be duplicated as they only need to happen on the days you are working on that project.


答:
Two product backlogs for one team.

Otherwise, should you ever grow to have two scrum teams, the cost of "sorting" out of the product backlogs will effectively prevent you from dividing the work.

Title: How should we implement Scrum with two projects for one team?

Body:
I'm starting at this new company as a scrum master, and they want to dive into Scrum, which is nice and all, but they only have enough people (4) for one team.

The road map includes delivering a new product and maintaining the old one, so what should we do?

2 products backlogs for 1 team? How should we do planning in this case?

1 product backlog for 2 products? How will sprint review work in this case?


答:
The first thing to keep in mind is that Scrum calls for a team of around 10 or fewer people. With a team of 4 people, you are at the lower threshold for seeing the benefits of the Scrum artifacts and events, but putting the framework into place would likely help if the team grows.

Things like the product backlog, sprint backlog, and various measurements and metrics (such as velocity and burndown) should be managed on a per-project basis. You would carry out all of the activities normally. You also need to track how much time each individual will be spending on each project so you know how many story points to pull down for each project. Rather than basing velocity on just story points per iteration, also consider the time spent on each project.

ContentLicense: CC BY-SA 4.0


答:
I have so far been given only vague reasons for not having source
  control - what reasons would you suggest could be valid for not
  implementing source control, given the information above?

The product you're developing is a version control system; managers are concerned about preventing existing products from influencing the design and implementation of the new product.

Between weekends of BASE jumping and running with bulls, thrill-seeking managers enjoy driving to work wondering whether everything's gone to hell yet.

Avoids hostile takeovers. Who would want to acquire a software development outfit that's managed this way?

Are there any more reasons for source control that I could add to my arsenal?

You're already doing version control, but you're currently doing it in the least efficient, most labor-intensive, most error-prone way imaginable. Using a VCS will save money, save time, and improve quality.

Saves disk space. Most version control systems save only the deltas between files. Currently, you're saving an entire copy of every version of every file. (Backing up all those copies must take a lot of time and space!)

Several developers can work on the same file at the same time and reconcile the differences without too much trouble. Merging changes is of course possible without a VCS, but it's nearly impossible to keep track of who changed what, when, and why in that case.

Gives developers freedom to try new ideas knowing that they can recover any version at any time.

Better process makes it easier to hire and retain talented developers.


问:
Should a developer argue against unnecessary or harmful features?
What is a good attitude from developers when discussing new features, and namely, non critical/questionable features?

Say you are developing some sort of Java like language, and the boss says: "We need pointers so that developers could fiddle with object memory directly!"

Should the developer shoot down the idea because it adds unimaginable complexity and security vulnerabilities, or should he do what's asked?

This may not be a good example, but what about things that are more in a gray area, like adding buttons that break workflow, or goes against internal structure of the program, etc.?

What is the optimal "can do" vs. "can't do" distribution for a regular programmer?

EDIT: The question is not about a bad boss :D

I was more interested how do people approach new problems that add a noticeable amount of problems while maybe being marginally useful.

Should the general attitude be:

yes we'll do it, screw the complexity

maybe

no, the general rework, and implications don't justify the change

What should be the reaction of a good developer?

答:
If your boss tells you to do stupid tasks, then you should (kindly) explain why it is stupid.

If he or she does not get the point, then you are obligated to do stupid things. That's it. He's the boss. In such case you can just do what he/she says, or talk to his/her boss or change the job.


答:
You could tell the boss that while it's technically possible, it will cost X amount in time and money spent on effort on analysis, design, to rewrite existing code, testing, regression testing, ... And then ask if the feature is worth it. Sometimes the answer will be "yes! we must have this!", sometimes it will be "no, I guess not".

If the feature being asked for violates some core principle of the application (such as "Add a blue button!" to a UI that is spec'd and designed to only have red buttons as per the customer's request) then I think it is OK to ask "Why?" and mention that it goes against the pre-established design.

In the end, almost everything is a "can do" (it may not not hard from a technical point of view to add a red button to a blue-only UI), it's more a question of "should do?"

To answer your edited question, I think the answer should be #2, "Maybe", pending further investigation and analysis.

You don't want to answer #1 "Yes, unconditionally" because you could get stuck committing to something you're not capable of delivering in the given timeframe.

You don't want to answer #3 "No, it's too much work" because then it looks like you are being uncooperative and needlessly difficult.

Title: Should a developer argue against unnecessary or harmful features?

Body:
What is a good attitude from developers when discussing new features, and namely, non critical/questionable features?

Say you are developing some sort of Java like language, and the boss says: "We need pointers so that developers could fiddle with object memory directly!"

Should the developer shoot down the idea because it adds unimaginable complexity and security vulnerabilities, or should he do what's asked?

This may not be a good example, but what about things that are more in a gray area, like adding buttons that break workflow, or goes against internal structure of the program, etc.?

What is the optimal "can do" vs. "can't do" distribution for a regular programmer?

EDIT: The question is not about a bad boss :D

I was more interested how do people approach new problems that add a noticeable amount of problems while maybe being marginally useful.

Should the general attitude be:

yes we'll do it, screw the complexity

maybe

no, the general rework, and implications don't justify the change

What should be the reaction of a good developer?


答:
Best thing is to have a meeting and lay out the pros and cons as a group, and based on that discuss the best solution. If you have a team, get them to agree on solution. Once a team agrees on something, managers and "bosses" tend to go with the solution.

If your boss still does not agree, then you've done all you can do: you've gotten your team and managers together and covered the pros and cons and despite that your boss chose a potentially inferior solution.

The key to this is discussing the pros and cons as a group. By doing so you are discussing what the best solution is with your team, and at the same time are pointing out your boss's decision (before he makes it) without the political backlash of going around after the fact telling people why you think your bosses decision was the wrong one.

This is a tender situation involving work politics, but it can be handled amicably.


答:
Since the question is pretty vague, i'm gonna generalize a bit with my response.

Always question them, but listen to their reasoning. Sometimes, people just forget about the practicality of a feature or how long programming it would take. On the flip side, we sometimes get locked into a programmer mentality of being efficient/no frills/etc and we forget that what we consider as non-essential for a project really isn't for the client.

If they have a good reason, then let them know how long it would take to program it and all the possible bumps that you'll run into during implementation and see if they will still want to proceed with it. Otherwise, state why you don't think that it's a good idea and see what their reaction is. Rinse and repeat.


答:
In an ideal scenario you'd have a Lead Developer that makes final decisions on the technical side and a Business Lead that makes final decisions on the business side.  This would answer the two main questions:

1) What? What does the customer want?

2) How? How do we accomplish this from a technology perspective.

What the customer wants is the ultimate decision maker as they are the ones who pay the bills


答:
From the perspective of a developer: NEVER tell anybody paying the bills that they can't have what they want. Instead, you may tell them they can't have it for that price, or that they can't have it exactly the way they originally conceived it.

To your "pointer" example; .NET, a managed-code environment, has pointers. They are critically necessary for a lot of interoperability with unmanaged code. However, "safe" use of them is tightly regulated, and if used in "unsafe" code, that code requires higher security permissions in the runtime. If you were developing a managed language that also required direct memory access via pointers, you could come up with a similar scheme of marshalling behind the scenes where you could, using read-only managed pointers where you couldn't automatically marshal, and allowing "true" pointers only in the most trusted areas of the codebase.

To your GUI examples: if you know that a new feature will "break" the current flow of code, then you can test for that and develop it more robustly to roll back any previous work done by the workflow. Your clients, and sometimes even your manager, usually have no clue or interest in the structure of the program; if something they want is difficult because of the way you structured the program, then by definition the structure is wrong because it does not allow you to do what the client wants.

In all cases, this new feature may increase the scope of work required beyond what the client had thought it would be. That will in turn require either an extension to the schedule, more money, and/or a reduction of other planned work.

However, if you know a way to achieve the same basic result in an easier or more logical way, then that can be suggested to the client. Although they definitely do exist, I fortunately have yet to see a client that refused categorically to listen to input from developers, especially in an Agile environment where there's a "product owner" whose sole job is to liase with development on various needed details such as these.


问:
What's the best way to organize our unit tests
We've built up a substantial number of unit tests for our main program over the years. Several thousand. The problem is that we don't have a clear idea of what tests we have because there are so many. And that's a problem because we don't know where we're weak on tests (or where we have duplicates).

Our app is a reporting engine. So you can have a template that is used to test parsing (do we read all table properties), merging in data (did we keep the correct table properties in the merge), formatting the final page (is the table placed correctly on the page), and/or the output format (is the created DOCX file correct).

Add to this what we need to test. Take the padding around a table cell (we use Word, Excel, & PowerPoint for the report design). We have to test the padding across page break, for a table inside a cell, vertically merged cells, horizontally merged cells, a vertically & horizontally merged cell that contains a table with a vertically & horizontally merged cells in the inner table, where that table breaks across a page.

So what category does that test go in? Table padding, page breaks, nested cells, vertically merged cells, horizontall merged cells, or something else?

And how do we document these categories, name the unit tests, etc.?

Update: A number of people have suggested using coverage tools to verify that we have full coverage. Unfortunately that is of limited use in our case because the bugs tend to be due to specific combinations so it's code that has all been tested, but not in that combination.

For example, we had a customer yesterday that started a Word bookmark at the end of a forEach loop in their template (a Word document) and ended it in the beginning of the next forEach loop. This all used code that has unit tests against it, but we had not thought of the combination of a template expanding a bookmark start to be started 25 times, then ended 10 times (the two forEach loops had a different number of rows).

答:
In .NET, I tend to mirror, or at least approximate, the namespace structure for the source code in the test projects, underneath a "Tests.Unit" or "Tests.Integration" master namespace. All unit tests go in one project, with the basic structure of the source code replicated as folders within the project. Same for integration tests. So, a simple solution for a project might look like this:

```<code>Solution
   MyProduct.Project1 (Project)
      Folder1 (Folder)
         ClassAA (Class def)
         ...
      Folder2
         ClassAB
         ...
      ClassAC
      ...
   MyProduct.Project2
      Folder1
         ClassBA
         ...
      ClassBB
      ...
   ...
   MyProduct.Tests.Unit
      Project1
         Folder1
            ClassAATests
            ClassAATests2 (possibly a different fixture setup)
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests
      ...
   MyProduct.Tests.Integration
      Project1 (a folder named similarly to the project)
         Folder1 (replicate the folders/namespaces for that project beneath)
            ClassAATests
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests
</code>```

For any AATs or AEETs that are coded with a unit-testing framework, this changes a bit; usually those tests mirror a set of steps, that will test the functionality of a new use case or story. I usually structure these tests in a MyProduct.Tests.Acceptance project as such, with tests for each story, possibly grouped by milestone or "epic" story which the story under development belonged to. However, those are really just uber-integration tests, and so if you prefer to structure the tests in a more object-oriented instead of story-oriented fashion you don't even need a MyProduct.Tests.Acceptance or similar project; just throw em in MyProduct.Tests.Integration under the scope of the highest-level object under test.

Body:
In .NET, I tend to mirror, or at least approximate, the namespace structure for the source code in the test projects, underneath a "Tests.Unit" or "Tests.Integration" master namespace. All unit tests go in one project, with the basic structure of the source code replicated as folders within the project. Same for integration tests. So, a simple solution for a project might look like this:

Solution
   MyProduct.Project1 (Project)
      Folder1 (Folder)
         ClassAA (Class def)
         ...
      Folder2
         ClassAB
         ...
      ClassAC
      ...
   MyProduct.Project2
      Folder1
         ClassBA
         ...
      ClassBB
      ...
   ...
   MyProduct.Tests.Unit
      Project1
         Folder1
            ClassAATests
            ClassAATests2 (possibly a different fixture setup)
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests
      ...
   MyProduct.Tests.Integration
      Project1 (a folder named similarly to the project)
         Folder1 (replicate the folders/namespaces for that project beneath)
            ClassAATests
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests

For any AATs or AEETs that are coded with a unit-testing framework, this changes a bit; usually those tests mirror a set of steps, that will test the functionality of a new use case or story. I usually structure these tests in a MyProduct.Tests.Acceptance project as such, with tests for each story, possibly grouped by milestone or "epic" story which the story under development belonged to. However, those are really just uber-integration tests, and so if you prefer to structure the tests in a more object-oriented instead of story-oriented fashion you don't even need a MyProduct.Tests.Acceptance or similar project; just throw em in MyProduct.Tests.Integration under the scope of the highest-level object under test.


问:
Why does everybody hate SharePoint?
Reading this topic about the most over hyped technologies I noticed that SharePoint is almost universally reviled.

My experience with SharePoint (especially the most recent versions) is that it accomplishes it's core competencies smartly. Namely:

Centralized document repository - get all those office documents out of email (with versioning)

User-editible content creation for internal information disemination - look, an HR site with current phone numbers and the vacation policy

Project collaboration - a couple clicks creates a site with a project's documents, task list, simple schedule, threaded discussion, and possibly a list of all project related emails.

Very basic business automation - when you fill out the vacation form, an email is sent to HR.

My experience is that SharePoint only gets really ugly when an organization tries to push it in a direction it isn't designed for. SharePoint is not a CRM, ERP, bug database or external website. SharePoint is flexible enough to serve in a pinch, but it is no replacement for a dedicated tool. (Microsoft is just as guilty of pushing SharePoint into domains it doesn't belong.)

If you use SharePoint for what it's designed for, it really does work.

Thoughts?

答:
The main reason I hate it is because it is SO horribly designed.  It's a massive configuration beast wrapped in layer after layer of opaque abstractions.  It looks more like an attempt to find new revenue for old technology than a serious attempt to provide a decent solution.  Frontpage, XML, web forms, CAML, MS Office, InfoPath, XML, XML, crap HTML, more Frontpage.

What year is it?  Just base your content types on actual table definitions.  Make it simple and work well like any modern CMS.  Microsoft really sucks at innovation.  Unfortunately, they  still own the enterprise space.

ContentLicense: CC BY-SA 2.5

Title: Why does everybody hate SharePoint?


问:
Which algorithms and data structures should a developer absolutely know?
I want to be a successful enterprise Java developer. With what algorithms and data structures should I be well versed? What books would you recommend to me?

To be a successful Java developer, do I need to know all the advanced algorithms such as those given in CLRS?

Can you suggest a list of the topics that I should learn in the descending order of their priority?

Must I know:

Searching?

Sorting?

Graphs/Trees?

etc?

答:
If you are to be a programmer of any kind you need to understand all the basic data structures ( stacks, queues, arrays, linked lists, hashtables, trees etc ) in some detail. Enough at least that you could implement any of them for yourself if you found yourself in a world with no collections frameworks to do the job for you.

With regard to algorithms, it seems to me that they are more tools for jobs, whereas your data structures are fundamental building blocks. I don't think it is as important to know the details of how to implement every algorithm that you might run into. What you do need to be able to do is evaluate how well an algorithm will work for a given purpose. Sometimes the difference between depth first and breadth-first search or the type of sort you perform on your data can make a very big difference to the performance or general success of your code, so knowing how to judge that is very important.


答:
If I read you correctly, the real question is about unknown complexity. Initially I read your question as, "I see the extremely likely risk of excess complexity but the boss doesn't" But you're saying that the boss isn't a problem, so I take it you're not sure what the risks of adding unacceptable complexity are.

In that case, I'd recommend some sort of risk mitigating strategy.  Image you're considering adding WCF/web services to your API, which could be awesome or a lot of complexity without reward:

add the feature on a branch. If it works, merge it. If it turns into a rats nest, kill it.

fire up a new one page project and do a proof of concept. If you can't do a proof of concept in a short time, then drop it. If the proof of concept works, make it bigger and integrate it with your

scour the web for people griping about that feature or technology. Where there there is a lot of griping going on, a technology might be some real risks of excessive complexity. Java Beans and COM+ are probably, old, but good examples of features that really jacked up the complexity and may or may not have delivered on the benefits side of the equation


答: According to comment I would not drive support of existing product by Scrum at all. Scrum is good for development where you can define backlog but maintenance usually cannot define it. It looks like the most effort must be put into your new project so lets handle with Scrum and reduce capacity of team by fixed time allocated to handle issues in the old product. If there will be no defects to fix the time will be used for a new product and team will probably be able to deliver little bit more than committed. If new feature for the old product will be planned you can count with it in the planning of the next sprint for the new product and reduce team capacity even more to get people enough time to implement a new feature for the old product.</p>


答:
I believe in pushing back bad requirements. But I also believe that when you have given your best shot at explaining why they are bad and they still want them, then you agree and do your job.

For instance, I have had people who want requirements that were mutually exclusive of something the application already does.  If I do that, then this will, 100% guaranteed, break. So I send the requirement back and tell them that this will break this other business rule we already have in place and do they want to change this rule too? Often the small group which comes up with a particular requirement doesn't have access to the bigger picture of what the rest of the application may do. Most of the time when I've sent one of these back, the customer has realized that the intial rule was more critical and decided that the change they wanted wasn't worth it. When they have decided to make the change they did it after consulting with the people who pushed the initial requirement.

Sometimes just asking clarification questions will make them see the issue is not as simple as they thought it was. Sometimes you want to ask why they want something and come to the real need that is driving the change. Once you understand that, it is often easier to see an alternatve solution that works for you as the developer and meets their need. If you can present that solution in terms of how it will better meet their need than the orginial suggestion, you have vastly improved your chances of having your change accepted.

Sometimes when a change is going to create havoc at a basic level in your design, just giving them the new estimate of hours the change will take is enough to get it turned off. If you combine that with a risk assessment that points out what critical functionality you might be introducing new bugs into with telling them it will take 6 weeks of dedicated effort by 3 people, suddenly it isn't so important any more.

But sometimes you tell them this isn't a good idea and why and they still say, "Too bad we need it." You win some and you lose some and sometimes the business needs genuinely have changed and the application must accomodate that. Once the decision has been finalized, it is no longer the time to question what you are doing and time to get on with doing it. If you have documented your objections, then you personally should still be in a good place when it goes over budget and causes new and more exciting bugs. And they might even be more willing to listen to you next time when you have built up a track record of being right on these sorts of things.

The key to winning many of these discussions (nobody wins all of them) is first to build up a track record for knowing what you are talking about. Next send a written document that states what concerns you have (many managers are risk adverse, they are more likely to not want someone to have a document that proves them wrong later, so they pay more attention to what you put in writing) and finally to make sure they understand all the costs (not just hours, but security risks, introducing new bugs, missing deadlines, etc.) of making the change. Change is not free and they need to understand that.  The next key is to do this like an adult and not like a whining child ("but I don't wanna use ... because I don't like it"). Make a business case for not doing it and you will get a lot farther in pushing back a bad requirement.


答:
I have previously been the Scrum Master for a team that was developing two products. The covered the same market space so it was understandable we would work on both of them.

We created roadmaps and developed stories independently and then combined them into a single backlog. That way we always knew which product took priority and could select items to work on appropriately. It was much more work for the Scrum Master and Product Owner, but made it easier on the rest of the team since they just viewed each story as a bit of work and didn't give much thought as to which product was more important.

The biggest challenge for the Product Owner was nailing down the priority between stories. One product had a larger installed customer base, but was in sunset because of technical limitations and the other had a long list of "must have" features. It was a balancing act to keep getting out new releases of the old to hang on to existing customer while providing new features in the new to attract new customers and (more importantly) get existing customers to migrate. In the end he had worked it out so the backlog was a pattern of 4 product A stories followed by 1 product B story. We had played with it a lot to that point and I know that since I've left they are still making adjustments based on the business needs.

His other big challenge was determining what frequency he wanted to release updates. Although both products were kept shippable at the end of iterations, it became as much a strategic decision of how releases would appear to the customer. In the end he settled on quarterly releases of the new and old, with the old coming out a week or two later. I can't say if that was the best decision or not.

In my role as Scrum Master, running interference for the team from outside forces was more complicated as people outside the team were frequently a positive influence on one product, but a negative on the other. For example, people we needed to consult with regarding the technology in the old product would sometimes try and make demands on changes to the new product in the middle of an iteration. So I needed them to sit with the developers, but keep focused on why we had them there.

There was also a lot of work in getting the team to see value in working on either project. While there is always better and worse assignments within a project, getting someone to pick up a dull task in a dying project for an iteration means you really need to sell the value of the work. Sometimes you had to highlight the dollars involved in the change.

Another issue the popped up every few months was a suggestion from upper management that we split the team into "vision" and "maintenance" teams. This was a group where people had been members for 3-10 years and they were suggesting splitting it just to make the resource allocation look better on paper. In reality, it would have hurt to take anyone off the maintenance permanently and by the same token not making someone part of the vision would have left them jaded or worse. I was constantly selling the value of the team as a whole was greater than the sum of its parts.

Estimating stories was difficult whenever we were picking up an area that hadn't been touched in a long time. It became difficult for the team to remember easily what other work had been done there and how they had sized it previously. This just meant that before estimation meetings I had to spend a few hours digging around through our old iterations to find similar stories so I could remind them of what else we had done in that area. How it had been sized and how the story had worked out in reality.

Another mechanical issue with the Scrum was running daily stand-ups in a way that kept it clear which product we were talking about. We adopted the approach of talking down through the stories rather than around the room to keep it clear. This was especially important when both products were updating the same technology in the same iteration.


答:
If you spend many years programming for large applications, and think critically about it along the way, you will develop a finely tuned sense of when a feature is going to cause problems that outweigh its usefulness. Another word for this is wisdom, and just as is the case with other kinds of wisdom, it can be a challenge to make those without it see its value.

Other posters have argued that you should try to quantify the cost of the problem that will be introduced by a problematic feature, and that is a good idea when it is possible, but usually it is not. It is usually only possible to estimate immediate implementation costs. Even that is often difficult for larger features. As for the future costs, you are in a tough spot. You don't know with certainty what other features will be required, or how long the product will be under maintenance. The cost will usually be much higher than you could back up with an estimate based on hard facts.

The more competence you have demonstrated in the past, the more leeway you will have to simply declare a feature a bad idea. That can only come with time and a demonstrated record of success. That said, you should always express eagerness to fulfill the request, since it is what your client wants. You should express reservations based on your experience, and once you have, it becomes a non-issue in 90% of cases because you will start a conversation that gets to the root of the issue, which is: Why have they asked you to add this feature in the first place? At that point you can offer alternatives, or perhaps agree that although the requested feature will introduce problems, it is still necessary.

Of course it is also possible that you are just wrong. Isn't software engineering fun?


答:
Argue no. Discuss possibly yes. But it should be treated as an addition to the spec and prioritized with other features. If you know that the request will add an unreasonable amount of time and complexity to implement then state that up front. Not as opposition to doing the request, just as an explanation of what you think it will take to implement.

It does very much depend on the request. Pointer implementation is big enough to effect an entire project so its merits should be weighed if given a choice.

Implementing a button that breaks the flow. Maybe not such a big deal if the form can be laid out in a way that the button is optional. I have done this very thing in fact. I added the button but also collected enough information before hand that the button became optional. Users who expected it to be there used it and those who realized it was just redundant didn't.

It's all about balance and knowing when to pick your battles. Some things are easier to just implement anyway versus dealing with the social aspects of not including it.


问:
how could I draw the database transaction commit in the sequence diagram
How could I draw the database transaction commit in the sequence diagram?

EDIT

I want to draw in sequence diagram database transaction commit/rollback process

答:
First, define use cases for the transaction you are modeling. Define versions of the use case for happy path, and each of the rollback scenarios you wish to model. Each of these use case variations can be presented as a separate sequence diagram.

Consider a very simple transaction -- client updates two tables, T1 and T2. Both updates need to succeed, or neither table gets changed. There are three interesting use cases --

The Happy Path -- both updates succeed.

Update to T1 fails.

Update to T1 succeeds, update to T2 fails, update to T1 is rolled back.

So you have three sequence diagrams, one for each case.

The third sequence diagram might look like this:

```<code>Client           Database
   |                  |
   |--begin trans.--->|
   |                  |
   |<-trans. started--|
   |                  |
   |----update T1---->|
   |                  |----:
   |                  |    :
   |                  |    DB established rollback point
   |                  |    :
   |                  |<---:
   |                  |----:
   |                  |    :
   |                  |    DB Updates T1
   |                  |    :
   |                  |<---:
   |<---T1 updated----|
   |                  |
   |----update T2---->|
   |                  |----:
   |                  |    :
   |                  |    Update Fails
   |                  |    :
   |                  |<---:
   |                  |----:
   |                  |    :
   |                  |    DB Rolls back T1 Update
   |                  |    :
   |                  |<---:
   |                  |
   |<---trans. error--|
</code>```

Body:
First, define use cases for the transaction you are modeling. Define versions of the use case for happy path, and each of the rollback scenarios you wish to model. Each of these use case variations can be presented as a separate sequence diagram.

Consider a very simple transaction -- client updates two tables, T1 and T2. Both updates need to succeed, or neither table gets changed. There are three interesting use cases --

The Happy Path -- both updates succeed.

Update to T1 fails.

Update to T1 succeeds, update to T2 fails, update to T1 is rolled back.

So you have three sequence diagrams, one for each case.

The third sequence diagram might look like this:

Client           Database
   |                  |
   |--begin trans.--->|
   |                  |
   |<-trans. started--|
   |                  |
   |----update T1---->|
   |                  |----:
   |                  |    :
   |                  |    DB established rollback point
   |                  |    :
   |                  |<---:
   |                  |----:
   |                  |    :
   |                  |    DB Updates T1
   |                  |    :
   |                  |<---:
   |<---T1 updated----|
   |                  |
   |----update T2---->|
   |                  |----:
   |                  |    :
   |                  |    Update Fails
   |                  |    :
   |                  |<---:
   |                  |----:
   |                  |    :
   |                  |    DB Rolls back T1 Update
   |                  |    :
   |                  |<---:
   |                  |
   |<---trans. error--|


问:
What factors should be evaluated when determining a desktop software price?
What factors should be evaluated when determining a desktop software price?</p>

答: The market?  Like any other product see what the going rate is for something similar.  See if you can find trusted clients and ask them what they think it is worth.</p>


问:
How can I thoroughly evaluate a prospective employer?
We hear much about code smells, test smells, and even project smells, but I have heard no discussion about employer "smells" outside of the Joel Test.  After much frustration working for employers with a bouquet of unpleasant corporate-culture odors, I believe it's time for me to actively seek a more mature development environment.

I've started assembling a list of questions to help vet employers by identifying issues during a job interview, and am looking for additional ideas.   I suppose this list could easily be modified by an employer to vet an employee as well, but please answer from the interviewee's perspective.

I think it would be important to ask many of these questions of multiple people to find out if consistent answers are given.  For the most part, I tried to put the questions in each section in the order they could be asked.  An undesired answer to an early question will often make follow-ups moot.

Values

What constitutes "well-written" software?

What attributes does a good developer have?  Same question for manager.  Who are your most valued employees/managers, and why?

Process

Do you have a development process?

How rigorously do you follow it?

How do you decide how much process to apply to each project?

Describe a typical project lifecycle. Ask the following if they don't come up otherwise:

Waterfall/iterative: How much time is spent in upfront requirements gathering? upfront design?

Testing

Who develops tests (developers or separate test engineers?)

When are they developed?

When are the tests executed?

How long do they take to execute?

What makes a good test?

How do you know you've tested enough?

What percentage of code is tested?

Review

What is the review process like?

What percentage of code is reviewed?  Design?

How frequently can I expect to participate as code/design reviewer/reviewee?

What are the criteria applied to review and where do the criteria come from?

Improvement

What new tools and techniques have you evaluated or deployed in the past year?

What training courses have your employees been given in the past year?  What will I be doing for the first six months in your company (hinting at what kind of organized mentorship/training has been thought through, if any)

What changes to your development process have been made in the past year?

How do you improve and learn from your mistakes as an organization?  What was your organizations biggest mistake in the past year, and how was it addressed?

What feedback have you given to management lately?  Was it implemented? If not, why?

How does your company use "best practices?"  How do you seek them out from the outside or within, and how do you share them with each other?

Ethics

Tell me about an ethical problem you or your employees experienced recently and how was it resolved?

Do you use open-source software?  What open-source contributions have you made?

Follow-Ups

I liked what @jim-leonardo said on this Stack Overflow question:

Really a thing to ask yourself: "Does this person seem like they are trying to recruit me and make me interested?" I think this is one of the most important bits. If they seem to be taking the attitude that the only one being interviewed is you, then they probably will treat you poorly. Good interviewers understand they have to sell the position as much as the candidate needs to sell themselves.

@SethP added:

Glassdoor.com is a good web site for researching potential employers. It contains information about how specific companies conduct interviews...

答:
Some has touched on this but not specifically: ask for things you hate as if you liked them. For example, if you dislike the idea of paired programming (to take an example from Demian Brecht) do ask about it.

Finally. always ask: "What is the most frustrating thing about your job?"


问:
Workflow design for multi-step edits on a webapp
I have a web app (ASP MVC2) where some forms can be accessed via multiple routes, initially once a form was complete a user was kicked back to a default page for that form rather than the page they entered it from.

Now I'm redesigning a sizable area I want to address this, I want a solution that is easy to add in. I have a couple of ideas but I'm not sure which to go with, I do know that I want it to be "invisible" (ie not touching my URLs).

So I'm thinking either:

I could have hidden fields for the referrer page on the forms.

Alternatively I could use TempData and have an attribute that handles checking and adding the referrer URL (this would likely include a string for each of the different pathways so that a user could have 2 different forms open and not have the referrers interfere).

The problem with the form value is that it would require putting non-model related fields in each of the views and would break if there's ever any GET requests in the workflow. it would also require manually handling this property in each view and action.

The TempData+attribute approach would be a much neater way to apply this but it's possible for powerusers who are doing many things at once to have conflicting referrers for the same forms.

I'm leaning towards the latter approach as it's more elegant and easier to keep track of as I don't see there being many of the edge cases where it gets overridden but I'm worried about the user experience for if it does happen. Is the trade off worth it?

答:
It is not clear to me what technology you are using for this so I will try to answer generically.

It sounds like users can have the form open more than once (new window or multiple tabs) launched from different contexts or more than once from the same context.  This would make using session variables an issue especially with your concern of a get removing form variables from the page.

You may instead want to look at creating the form as a template (User Control in .NET) and including it in a page for each of the contexts where it is used.  The parent page could have a single static variable that holds the value for the context.  When processing get the values for from the form and the context from the parent page the form is in and on success redirect back to the appropriate location for the context.  This of course assumes that the route and redirect you talk about can be tracked with one variable.  That variable plus information on the form could also be used for various return locations.


答:
Some factors I would consider:

Going market price of similar software.

Margin of profit you wish to make.

Cost of bringing software to market (i.e. distribution costs).

Third-party licensing costs (if third-party software is used).

Body: What factors should be evaluated when determining a desktop software price?</p>


答:
Most is already said, but there is one thing I would emphasize in my current work environment. I work for a company that is a contractor for other companies and out applications are business process related ( to a fair amount they drive sales and customer communication ).

Business processes along with the accompanying products can be ( at least if the company is big enough ) very complex. To a certain degree, if you are modelling a complex thing, the resulting application will have a relating complexity. As most individuals of the business people only see their part of the process the complete application/process builds on a greater complexity than what is visible to just one user.

My point is, that when a new business requirement arises, it will work for the business people, because it doesn't raise the complexity much higher, but may have a greater impact on the whole system. In my opinion this is not a reason to argue against that change. It is the right point to discuss the efforts ( and the expenses ) with the customer. It probably won't stop the customer to have that feature build, but by time they will gain a feeling for the applications and some discussions about "uuh, you're that expensive!" will be much less picky.

I do not know whether you are in a comparable situation, but I have learned that the stakeholder's situation doesn't necessarily has the same complexity raise imminent like the one that developers and architects of the IT system face. In that situation communication helps both sides.


答: My company uses GIT for version control. The company is one developer, one CEO, one security guard, one cleaning lady and one recepcionist. All of them are me. Source version control is a MUST everytime.</p>


问:
What is a "Process Canary"
In the book "Hard Code" by Eric Brechner, he states,

Lying is one of a handful of valuable process canaries that can warn
  you of trouble.

I've heard a dev or two toss around the old "canary".  What is it?

[Google didn't answer it for me.  Perhaps my keywords were a poor choice.]

答:
Canaries were once used in coal mines to find out if any poisonous gasses were around (the canary would die - the miners would get out). It was much safer than an open flame.

One assumes in this context that if there is much lying, the process is poisonous.

Title: What is a "Process Canary"


答:
It just means a red flag, referring to the use of a canary in coal mine.

...caged canaries (birds) that mining workers would carry down into the mine tunnels with them. If dangerous gases such as methane or carbon monoxide leaked into the mine, the gases would kill the canary before killing the miners, thus providing a warning to exit the tunnels immediately...

Title: What is a "Process Canary"

Body:
In the book "Hard Code" by Eric Brechner, he states,

Lying is one of a handful of valuable process canaries that can warn
  you of trouble.

I've heard a dev or two toss around the old "canary".  What is it?

[Google didn't answer it for me.  Perhaps my keywords were a poor choice.]


答:
I take it, you're entering a market with a well-placed competing product. So a big piece of the cake you want to get, is already using another product. For them, switching to your product represent an investment:

Assuming, you provide a real alternative, it will probably take them a while to get used to.

Anyone who chooses tools, attaches himself.

They have already paid for the competitor's product.

Therefore, you should try keeping the actual monetary cost for switching low, and possibly provide some tutorials for users coming from the other product.

Pricing models you should consider:

A subscription based payment model.

Charging for upgrades.

Charging for extra features.

Title: What factors should be evaluated when determining a desktop software price?


答:
On my first serious job in 1990 I was the only developer working in my department and didn't know to use source control.

Pretty soon thereafter I learned, from then on I've never seen a project that didn't make it one of the first things they set up.

I nearly lost all my work at that job because I deleted a folder at the wrong level.  Luckily I had brought a copy home on a 5" floppy the week before and was able to re-create the weeks work in a few long days.

So I guess I'd consider it acceptable if it was the first project for everyone on the team and nobody knew better, but if even one person could actually explain the benefits and the team still didn't listen I'd re-categorize my opinion of the group from "naive" to "dangerously incompetent" (Resistance to using a tool with such widely-demonstrated benefits is almost criminal--it's like if your team didn't trust "Compilers" and insisted in doing everything in assembly language).


问:
Is the agile approach too much of a convenient excuse for cowboys
I believe that an agile approach is best for projects where the requirements are fuzzy and a lot of interaction is required to help shape the end user's ideas.

However... In my professional work, I keep ending up at companies where an "agile" approach is used as an excuse as to why no effort was put into an up front design; when the requirements are well understood.

I can't help but thinking that if the agile approach wasn't around, I'd be sitting here with a nice high-level specification and not having to revisit the same screen and functionality every second day when something else crops up or so and so hadn't thought of that.

Are the benefits of agile methodologies really enough to outweigh the excuse for being lame it gives to cowboy technical leads?

Update: Ironically I'm now a certified Scrum Master. One of the papers presented on the Scrum course observed that the best development process was one where there was a single expert or guru making the design decisions, however that has obvious weaknesses. Scrum shifts the responsibility for producing quality software to the "Team" which means a sub-standard team can get away with churning out spaghetti which I guess is no different to other Agile and non-Agile development processes.

答:
I'd be sitting here with a nice high
  level specification and not having to
  revisit the same screen and
  functionality every second day as
  something else crops up or so and so
  hadn't thought of that.

That does seem to tally with my colleague's experience of the "agile" project he is on (I've never been on one myself): he is asked to write a piece of code to some spec, then just as he's finished testing it and is ready to move on a new requirement comes up that requires him to change it and re-test it.  He finds it frustrating.

I'm not bashing agile, I suspect the team is not doing agile properly - but as you say, the term "agile" can sometimes be used by cowboys to convince pointy headed management that half-baked design is a positive rather than a negative.


答:
The problem I see is your use of the word argue.

You must bring up design issues and the reasoning behind them, but be wary because programmers have a tendency to get defensive about positions they have taken and argue points just for the sake of arguing (Sometimes).  I have to stop myself from arguing quite a bit--and I don't always succeed.  Also as I get older I find I'm wrong more often than I used to be--or worse I didn't recognize how often I used to be wrong :)

If you have clearly stated requirements (the language must be safe, we need pointers to access legacy routines) then you could present how the two requirements conflict and ask which is more important.  Once you have the requirements and the reasons behind them you may even be able to come up with a completely different solution that supports both requirements (JNI--kinda).

If it doesn't, well perhaps it's a good time to codify them!


答:
As a developer, you shouldn't really care which requirements are requested to be implemented.

However, you should explain if something is unrealistic and if there are better ways.


问:
Do you prefer conciseness or readability in your code?
Language shortcuts can often be used to make code more concise.

For example, ternary and null coalescing operators can reduce the amount of code, but arguably to the detriment of readability:

In C#:

```<code>Person newGuy = new Person();
if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
} else {
    newGuy.Boss = boss;
}
</code>```

is functionally equivalent to:

```<code>Person newGuy = new Person();
newGuy.Boss = boss ?? GetDefaultBoss();
</code>```

but obviously a lot more verbose.

Where do you draw the line when it comes to conciseness vs readability?

答:
I would say as a general rule never sacrifice readability because of conciseness, but never judge readability based on another programmers lack of knowledge on that subject.

Conciseness and readability are not opposites.  Like this answer, sometimes shorter is more readable.


问:
If multitenancy is a priority, should I store site content in the database?
I have a multi tenant ASP.NET MVC website and all client specific text is stored in resource files.  Every time someone wants to change text I have to jump through hoops and fill out forms and let someone else put it in production.  This was fine with 2 clients, but now we have 6 and are looking to roll out to 40+.  I can't spend all day making text changes!

Does anyone have any advice on how to make life eaiser?  I was thinking a CMS may not work because as far as i know most CMS's idea of multitenancy is to add an additional independent site.  We frequently roll out new features and I fear I'll be in the same boat adding modules and updating 40+ sites.  I prefer one site with different text if I can.

Any help is most appreciated!

答:
Yes, you certainly should store all client modifiable content into the database (or accessed via the database) so that the clients can maintain this for themselves.

You will need to spend some time writing the admin functions but you will reap the rewards in the long run. You are right you cannot have the situation where all changes need to go through the developers. You will end up spending all your time updating the sites.

You can, and probably should, introduce the changes gradually. Each time someone wants to change something add it (and a few related things) to the admin pages. That way you'll only have admin for the things that people actually want to change and not for the rest.

A few years ago I worked for a company producing themed sites for local papers and when I started there were few admin pages for these sites and my team were in the same position as you. I gradually introduced admin pages and everybody was happy. The team was happy as they could concentrate on development, the clients were happy as they could get their site updated when they wanted, the management were happy as the clients were happy.

OwnerDisplayName: Gary Green


问:
What are some patterns and anti-patterns of application logging?
I recently had to investigate a field issue for our large enterprise application. I was horrified by the logs that I had to comb through in an attempt to find the problem and at the end of the day the logs did not help at all identifying/isolating the bug.

Note: I understand not all bugs are discoverable through logs. This does not change the fact that the logs are horrible.

There are some obvious problems with our logging that we can already attempt to fix. I do not want to list those here and I cannot simply show you our log files so you can give advice on what to do.

Instead, in order to assess how bad we are doing on the logging front, I would like to know:

What are some guidelines, if any, when it comes to logging for an application, especially large application.

Are there any patterns we should follow or anti-patterns we should be aware of?

Is this an important thing to fix or can it even be fixed or all log files are simply huge and you need supplemental scripts to analyze them?

Side note: we use log4j.

答:
My favorite public resource for logging guidelines are Apache JCL Best Practices.

Best practices for JCL are presented in two categories: General and Enterprise. The general principles are fairly clear. Enterprise practices are a bit more involved and it is not always as clear as to why they are important.

Enterprise best-practice principles apply to middleware components and tooling that is expected to execute in an "Enterprise" level environment. These issues relate to Logging as Internationalization, and fault detection. Enterprise requires more effort and planning, but are strongly encouraged (if not required) in production level systems. Different corporate enterprises/environments have different requirements, so being flexible always helps...

Despite targeting JCL, these seem to be generic enough to be adopted for logging in general.

My personal "guidelines" for logging is that at debug level, I try to make my logs read like a story - with understandable logic and sufficient (but not overloaded) details.

Most famous anti-pattern is probably "swallowing exceptions" - just search the web for it.

As for huge logging files, in my practice this was mostly the normal case. And yes, supplemental scripts as you call them and/or tools like Chainsaw also look normal to me.

Above doesn't mean though that you must always blindly put all the logs in one huge file. Sometimes it could be useful to write / copy some of the logs to separate files. Eg in my recent project QA guys asked for dedicated files for metrics and timing data and for brief reports on system operations. They said they will benefit from that and dev did it (benefit from brief reports file turned out indeed significant).

PS. Regarding anti-patterns, others that come to mind are "flooding" and senseless messages.

I call it flooding when I see multiple similar messages coming from a loop with many iterations. To me, flooding is annoying enough to try to get rid of it when I detect it in source code. Usually improving it requires some art - because, well, things that happen within the loop may be interesting. When I don't have time to improve it deeper, I try to at least change logging level of such messages to lowest one to make it easier to filter out.

Senseless messages seem to be pretty popular garbage. These look harmless when read in source code - I guess one has to go through the pain of analyzing debug output looking like...

```<code>step #1
step #2
step #3
</code>```

...to deeply appreciate their inherent ugliness. My favorite heuristics to detect this kind of problems at source code level (proposed by colleague in one of my past projects) is to calculate number of space symbol occurrences in string literals used in logging. In my experience, zero spaces basically guarantees the logging statement is senseless, one space is also a good indicator of the potential issue.

Body:
My favorite public resource for logging guidelines are Apache JCL Best Practices.

Best practices for JCL are presented in two categories: General and Enterprise. The general principles are fairly clear. Enterprise practices are a bit more involved and it is not always as clear as to why they are important.

Enterprise best-practice principles apply to middleware components and tooling that is expected to execute in an "Enterprise" level environment. These issues relate to Logging as Internationalization, and fault detection. Enterprise requires more effort and planning, but are strongly encouraged (if not required) in production level systems. Different corporate enterprises/environments have different requirements, so being flexible always helps...

Despite targeting JCL, these seem to be generic enough to be adopted for logging in general.

My personal "guidelines" for logging is that at debug level, I try to make my logs read like a story - with understandable logic and sufficient (but not overloaded) details.

Most famous anti-pattern is probably "swallowing exceptions" - just search the web for it.

As for huge logging files, in my practice this was mostly the normal case. And yes, supplemental scripts as you call them and/or tools like Chainsaw also look normal to me.

Above doesn't mean though that you must always blindly put all the logs in one huge file. Sometimes it could be useful to write / copy some of the logs to separate files. Eg in my recent project QA guys asked for dedicated files for metrics and timing data and for brief reports on system operations. They said they will benefit from that and dev did it (benefit from brief reports file turned out indeed significant).

PS. Regarding anti-patterns, others that come to mind are "flooding" and senseless messages.

I call it flooding when I see multiple similar messages coming from a loop with many iterations. To me, flooding is annoying enough to try to get rid of it when I detect it in source code. Usually improving it requires some art - because, well, things that happen within the loop may be interesting. When I don't have time to improve it deeper, I try to at least change logging level of such messages to lowest one to make it easier to filter out.

Senseless messages seem to be pretty popular garbage. These look harmless when read in source code - I guess one has to go through the pain of analyzing debug output looking like...

step #1
step #2
step #3

...to deeply appreciate their inherent ugliness. My favorite heuristics to detect this kind of problems at source code level (proposed by colleague in one of my past projects) is to calculate number of space symbol occurrences in string literals used in logging. In my experience, zero spaces basically guarantees the logging statement is senseless, one space is also a good indicator of the potential issue.


问:
Tips/advice on how to reduce the use of "manager" classes?
I sometimes hear that having too many "manager" classes in your program's design is code smell and add an unnecessary layer of complexity. To me it makes sense that people want to use manager classes for manipulating and controlling objects from a context that makes sense to them, but figuring out how to make a solution work without them can be confusing.

Should one really avoid manager classes as much as possible? Also, what articles/papers should I read on how to implement an alternative work around for general/common cases where these managers can be removed?

答:
There are maybe two reasons this is a code smell. One reason is, that it may mean you don't have domain objects but instead you have value objects that just store data for manipulation by controller or manager classes. This is actually pretty common and amounts to procedural programming in an OO language. The "lots of managers" may be a hint that you need to integrate state logic, validation and other direct concerns into the domain objects so that they actually encapsulate something. Of course there are bigger hints such as the fact that you have no methods other than getter/setters.

The other reason its a code smell is that it may mean your domain objects don't actually relate to each other very well. For instance if you have an Account class that really doesn't know anything about Transaction class except that it is named Transaction and there can be more than one of them, then you again you don't really have a very vibrant business domain implementation. For example SavingsAccount should maybe know that it can't accept a DebitTransaction if the accountStatus is closed. A lot of implementations would leave this up to the manager.


问:
What to do if boss always postpones major decisions about requirements and overall design?
When starting a new project, my boss always avoids to make fixed decisions. He is usually saying: ok, just start to write something and be as generic as possible. When you're finished we look how we continue. His argument is basically that you never know and "agile development".

To keep the question as generic as possible: what do you do if your boss doesn't like to make decisions?

Just stick to it and write code that might undergo heavy refactoring and partial rewriting a few weeks later? Or keep on discussing until the boss does at least a few decisions? This is more or less my current strategy. Because it's like a law of physics, at some point something needs to be delivered. Either because the boss' boss wants to see results or because stuff is becoming ridiculous at some point.

I also observe that my boss is criticizing nearly everything. Even suggestions that are based on his own...

答:
Point out to him that the Agile books suggest postponing decisions as long as you can but no more than that. Every decision has a point where it has to be made, and maybe you're there right now.

On the other hand, also question yourself. Do you really need to decide what persistence layer you're going to use for this app? Or can you start off writing it to a CSV and keep it abstracted enough to make that decision later?


答:
Build prototypes

Just start drawing screens that don't do anything at first (presumably you have enough to do that?)

You should be able to make it partially functional slowly, and eventually refactor some of the bad code when it becomes more clear what you are trying to do.

It's a common problem that they don't know what they want until they see something and realize that's not what they want.  I've found that when someone wants you to just start building 'a framework' or something 'generic' like what he is telling you, you are just going to get in trouble if you try.  The frameworks are already written, you don't need to do that.

Title: What to do if boss always postpones major decisions about requirements and overall design?

Body:
When starting a new project, my boss always avoids to make fixed decisions. He is usually saying: ok, just start to write something and be as generic as possible. When you're finished we look how we continue. His argument is basically that you never know and "agile development".

To keep the question as generic as possible: what do you do if your boss doesn't like to make decisions?

Just stick to it and write code that might undergo heavy refactoring and partial rewriting a few weeks later? Or keep on discussing until the boss does at least a few decisions? This is more or less my current strategy. Because it's like a law of physics, at some point something needs to be delivered. Either because the boss' boss wants to see results or because stuff is becoming ridiculous at some point.

I also observe that my boss is criticizing nearly everything. Even suggestions that are based on his own...


答:
There are several issues that I have gathered from your message:
0-It is not your job to manage the project and it is not your job to gather end-user requirements.
1-The boss does not know the exact requirements
2-The boss does not to talk to end-users about the requirements
3-The boss is throwing terminology he does not really understand agile
4-You are working out some solution that gets re-written several times and you are not happy about it

As for 1,2 and 3 there is little can be done about this if you are not a senior person. However, the following can be done:

A - Ask him to share with you the project plan. He may have one or will build one showing the tasks and deadlines. One of these should be about analysis and requirements gathering. If not suggest it.

B - Prepare some references on the importance of requirements to the success of software project

C - Prepare him a 1 page of what Agile is and is not.

D - Prepare him a list of typical inputs to the design stage and convince him of the value of each.

E - Suggest the addition of a business analyst and/or data modeler to the team. Such roles will have to sit with the end-user and will get you the information required or at least good part of it.

F - See how other developers cooped with this guy.

As for #4, you can suggest to him to use a prototyping approach or a code generator that would help him, you and the user to make their mind about the functional aspects of the application. Most tools don't generate perfect GUI, but at least you could capture the functionality required.

In all cases, make sure that you document each of the iterations clearly and send him an email about what input you have received, what you did (in some detail) and what the outcome is. Make sure you attribute the outcomes to the proper cause such as (lack of requirements, etc.).

Unfortunately some people don't accept advice. So be careful how you communicate with him.

This is not going well!

Good luck.


答: License, with respect to the long tail.</p>

Body: License, with respect to the long tail.


答:
You need to design and implement something. Since your boss won't make decisions then make them yourself. Take a little extra time to document your decisions and assumptions before you implement them. Send it to whoever it may concern including your boss.  Hopefully, that list includes more than your boss as it will put a little pressure on him to make some decisions since he knows that others are aware that you are ready to proceed. You will be surprised at how quickly you get feedback when you put decisions in writing, especially if you make decisions that other people disagree with. In the meantime, I would proceed with the decisions you made until told otherwise.

If you ended wasting time implementing what your boss didn't want, then it is on him and not you since he was aware of the path you were going to take.

Also, some people have a difficult time getting started, but once they see something tangible then their mind kicks in. Maybe your boss is like that and your telling him what you plan on doing in writing will get his mind going.


答: Write your own spec document and hold a review where you explain it and he signs off on it.  Then you will become boss, and your boss will move into more interpersonal management issues rather than technical issues.</p>


问:
Is it unusual for a small company (15 developers) not to use managed source/version control?
It's not really a technical question, but there are several other questions here about source control and best practice.

The company I work for (which will remain anonymous) uses a network share to host its source code and released code.  It's the responsibility of the developer or manager to manually move source code to the correct folder depending on whether it's been released and what version it is and stuff.  We have various spreadsheets dotted around where we record file names and versions and what's changed, and some teams also put details of different versions at the top of each file.  Each team (2-3 teams) seems to do this differently within the company.  As you can imagine, it's an organised mess - organised, because the "right people" know where their stuff is, but a mess because it's all different and it relies on people remembering what to do at any one time.  One good thing is that everything is backed up on a nightly basis and kept indefinitely, so if mistakes are made, snapshots can be recovered.

I've been trying to push for some kind of managed source control for a while, but I can't seem to get enough support for it within the company.  My main arguments are:

We're currently vulnerable; at any point someone could forget to do
one of the many release actions we have to do, which could mean whole
versions are not stored correctly.  It could take hours or even days
to piece a version back together if necessary

We're developing new features along with bug fixes, and often have to delay the release
of one or the other because some work has not been completed yet.  We also have to force
customers to take versions that include new features even if they just want a bug fix,
because there's only really one version we're all working on

We're experiencing problems with Visual Studio because multiple
developers are using the same projects at the same time (not the same
files, but it's still causing problems)

There are only 15 developers, but we all do stuff differently; wouldn't
it be better to have a standard company-wide approach we all have to
follow?

My questions are:

Is it normal for a group of this size not to have source control?

I have so far been given only vague reasons for not having source control - what
reasons would you suggest could be valid for not
implementing source control, given the information above?

Are there any more reasons for source control that I could add to my
arsenal?

I'm asking mainly to get a feel for why I have had so much resistance, so please answer honestly.

I'll give the answer to the person I believe has taken the most balanced approach and has answered all three questions.

Thanks in advance

答:
The minority opinion:
I can always recover a file anytime I want from archives.
I design my programs in blocks that I can recreate quickly.
I even write code that generates C# code for faster development.
Those programs I backup, of course.
I have had problems with other programers who didn't understand jQuery for instance, who would undo my code.
I don't have to worry about merging and having go through the process of reconciling versions.
I am so much happier without SVN, and yuck Team Foundation.   </p>


问:
Can anyone recommend a toolchain-agnostic way of declaring and documenting inter-package build dependencies?
I currently have a project at my hand that I'll leave soon (PhD work) and should be left in an understandable form since it is likely to be taken up, though it is not known yet by whom and when.

Therefore, I'd like to leave at least some documentation how it is built. The project consists of 7 packages, each of which is an independent source code package whose compilation only depends on libraries and headers from other packages. The whole build process revolves around open source standards, i.e. each project is built by autoconf and automake, is Debian-ized and the interpackage dependencies are declared in the Debian packages and checked in configure scripts.

However, this feels like a quite specific way of specifying a quite general problem. It is likely that the next maintainer would want to build the software with a Windows GUI thingy that doesn't know anything about autoconf or Debian. I'd like to leave more rigid documentation in this case than a bunch of comments in the assorted INSTALL files and the Build-Depends/Depends declarations in the Debian files.

Is there any toolchain-agnostic established language or standard to document packaging and build order? Bonus points if the actual build system specifications (like Debian Build-Depends) could be generated from that.

答:
Graphviz is highly readable and editable in addition to the purpose of generating graphical output for documentation.  In a couple different projects over many years, I wrote some simple tools which generated graphviz output, or simply typed up the dep's manually.  The result is that the project managers and bosses all printed out copies and taped them to their whiteboards because they found the diagrams so useful.

One of these was for the entire dependency chain for a large gnu/linux embedded systems project, and there were dozens of dependencies between toolchain, binutils, gpl packages, etc, etc, etc.   The diagram became too large to fit on legal sized paper.

(Tangentially: this is the huge hidden cost of choosing gnu/linux: dozens of independent packages from authors who don't integrate their packages with each other.  If it were netbsd, the "system" would be just one product from one vendor: the netbsd release.)


问:
Is there a difference between property and attribute?
These two words are completely synonymous for me, but I wonder if there's actually a useful semantic difference that I can incorporate into coding/naming conventions/process.</p>

答:
The English words have overlapping meanings but slightly different implications. Property implies something possessed by something else. Attribute suggests something that is an inherent characteristic.

However, because their meanings almost completely overlap, you can substitute one for the other. The exception would be where the terms are jargon, for example in C# where property and attribute have different, much more specific, meanings. In HTML, there is something specifically called a tag attribute and calling it a property would be confusing.

If you're inventing new jargon for a specific context, I would say to prefer whichever sounds more natural. If it's something discrete that something else contains, I'd generally prefer property. If it's something that is an inseparable inherent characteristic of something else (and especially if it's something other things can have as well), I'd generally prefer attribute.


答:
The definition of Properties and Attributes are context sensitive based on the programming language/markup you're using.

In standard markup languages (XML, HTML, SVG, etc) an attribute is well defined

```<code><xml version="1.0"> <!-- The attribute here is version -->
</code>```

In other programming languages an Attribute is an object where a property is a stored value

```<code>public Attribute FirstName { get; set; } // C# Property which stores and returns an Attribute object :-D
</code>```

Title: Is there a difference between property and attribute?

Body: These two words are completely synonymous for me, but I wonder if there's actually a useful semantic difference that I can incorporate into coding/naming conventions/process.</p>

Body:
The definition of Properties and Attributes are context sensitive based on the programming language/markup you're using.

In standard markup languages (XML, HTML, SVG, etc) an attribute is well defined

<xml version="1.0"> <!-- The attribute here is version -->

In other programming languages an Attribute is an object where a property is a stored value

public Attribute FirstName { get; set; } // C# Property which stores and returns an Attribute object :-D