答: Could you try to paint the picture of them wanting X amount done in Y time and that in order to make that happen, it would be best to bring in my hands to assist in getting through that work?  A key point here is to be able to show that you are stretched and that it is probably quite risky to try to put all this on your shoulders while if there is another set of hands that can help quite a bit both for the organization, yourself and this individual.  Make it a win/win/win for everyone.</p>

Title: How do I convince my employer to hire an additional developer without selling myself short?

Body:
I'm the only developer at a small company. I've slowly moved into development here; until ~4 months ago 50-75% of my time was spent on operations. Now, 50-75% of my time is spent on development, with the rest split between operations and various IT stuff. I regularly end up working 50+ hours a week.

I inherited some rather poorly-written applications (they were previously maintained by two people) that much of the business relies upon. Keeping these up and running, working on new, smaller applications, and my other responsibilities already take up all my time.

In order to be scalable, the existing software needs significant refactoring and additional functionality. I haven't had the pleasure to work on properly written or architected software before. The complexity of this task is well beyond anything I've done before (this is my first job out of college.) I know there's a feverish devotion to self-learning/learning by doing among many here, but this is so beyond my expertise that I wouldn't be doing my employer or myself any favors trying to tackle it alone.

I've been very direct about my inexperience, and in the past have mentioned that hiring another, more experienced developer will probably be necessary...if anything, just for the amount of time required for anyone to do the work as we grow and have more software to develop and maintain. I know that I would greatly benefit from hiring another developer; having someone to learn from and bounce ideas off of would be great. StackOverflow is great for determining approaches to individual coding problems or concepts, but is no replacement for discussions on a wider or more significant scale specific to a certain business domain. When mentioning hiring another developer in casual conversation recently, they didn't seem to think it was that important or necessary.

tl;dr: Current patch jobs and other responsibilities already take up all my time at work, work on existing applications that needs to be done is beyond my skillset, little chance of me having any time to work on new products that are being planned. Employer initially seems reluctant about hiring another developer.

How can I "sell" hiring another developer without sounding like I'm lazy or incompetent (I'd like to think I'm neither!)?

edit: Just wanted to clarify that I'm in no way interested in taking any kind of hostile action to prove a point (i.e. taking a vacation to show them they'd be screwed if I wasn't around.) I'm pretty content working here and consider myself to be fairly compensated, even figuring in the overtime, which is why I'm nowhere near considering a new job yet. That said, I accepted the 'no more overtime' answer - even if I don't mind working over too much I'm not doing anyone any favors by doing so (prone to more errors, wear myself out) and it's not really tenable in the short term much less the long term. I'll be stressing this when discussing the matter with my supervisor, and will probably suggest hiring a contractor part-time as an initial approach that's more financially palatable. Thanks for all the great answers.


问:
How do I convince my employer to hire an additional developer without selling myself short?
I'm the only developer at a small company. I've slowly moved into development here; until ~4 months ago 50-75% of my time was spent on operations. Now, 50-75% of my time is spent on development, with the rest split between operations and various IT stuff. I regularly end up working 50+ hours a week.

I inherited some rather poorly-written applications (they were previously maintained by two people) that much of the business relies upon. Keeping these up and running, working on new, smaller applications, and my other responsibilities already take up all my time.

In order to be scalable, the existing software needs significant refactoring and additional functionality. I haven't had the pleasure to work on properly written or architected software before. The complexity of this task is well beyond anything I've done before (this is my first job out of college.) I know there's a feverish devotion to self-learning/learning by doing among many here, but this is so beyond my expertise that I wouldn't be doing my employer or myself any favors trying to tackle it alone.

I've been very direct about my inexperience, and in the past have mentioned that hiring another, more experienced developer will probably be necessary...if anything, just for the amount of time required for anyone to do the work as we grow and have more software to develop and maintain. I know that I would greatly benefit from hiring another developer; having someone to learn from and bounce ideas off of would be great. StackOverflow is great for determining approaches to individual coding problems or concepts, but is no replacement for discussions on a wider or more significant scale specific to a certain business domain. When mentioning hiring another developer in casual conversation recently, they didn't seem to think it was that important or necessary.

tl;dr: Current patch jobs and other responsibilities already take up all my time at work, work on existing applications that needs to be done is beyond my skillset, little chance of me having any time to work on new products that are being planned. Employer initially seems reluctant about hiring another developer.

How can I "sell" hiring another developer without sounding like I'm lazy or incompetent (I'd like to think I'm neither!)?

edit: Just wanted to clarify that I'm in no way interested in taking any kind of hostile action to prove a point (i.e. taking a vacation to show them they'd be screwed if I wasn't around.) I'm pretty content working here and consider myself to be fairly compensated, even figuring in the overtime, which is why I'm nowhere near considering a new job yet. That said, I accepted the 'no more overtime' answer - even if I don't mind working over too much I'm not doing anyone any favors by doing so (prone to more errors, wear myself out) and it's not really tenable in the short term much less the long term. I'll be stressing this when discussing the matter with my supervisor, and will probably suggest hiring a contractor part-time as an initial approach that's more financially palatable. Thanks for all the great answers.

答:
I regularly end up working 50+ hours a week

To me thats all you need to tell your manager. "Im working 50+ hours a week to make sure the work gets done. Im a hard worker but this is unsustainable long term, you should hire another developer". If that dosent work then I suggest you start looking for a new job.

ContentLicense: CC BY-SA 3.0


问:
When can you call yourself good at language X?
This goes back to a conversation I've had with my girlfriend. I tried to tell her that I simply don't feel adequate enough in my programming language (C++) to call myself good. She then asked me, "Well, when do you consider yourself good enough?"

That's an interesting question. I didn't know what to tell her. So I'm asking you.

For any programming language, framework or the like, when do you reach a point were you sit back, look at what you've done and say, "Hey, I'm actually pretty good at this."? How do you define "good" so that you can tell others, honestly, "Yeah, I'm good at X".

Additionally, do you reach these conclusions by comparing what others can do?

Additional Info

I have read the canonical paper on how it takes ten-thousand hours before you are an expert on the field. (Props to anybody that knows what this paper is called again)

I have also read various articles from Coding Horror about interviewing people. Some people, it was said, "Cannot function outside of a framework." So they may be "good" for that framework, but not otherwise in the language. Is this true?

答: You can't call yourself good at X.  Only other people can.</p>

ContentLicense: CC BY-SA 2.5


问:
Should you document everything or just most?
It seems a bit of a controversial subject to document everything, including the "JavaBean" syntax of getters and setters for fields: People say its needlessly long and repetitive breaking DRY (don't repeat yourself), that the naming convention should explain everything, and it clutters code/documentation. Sometimes those arguments work. But other times, you end up with this:

Above is common to open source projects that do boldly follow those principles. You're left with entirely useless documentation. That doesn't explain anything about what's going on underneath, the possible effects, or even what the expected value is (could it be null or never null? I don't know; the Javadoc doesn't tell me).

So when should I document? Do I document everything even if it occasionally clutters code? Or do I document nothing since in my eyes it's "obvious"?

答:
While I appreciate a clear and extensive documentation, there's nothing like self-documenting code. So, the bottom line (for me) is:

Be very suspicious of (source code) documentation; try and make it redundant by improving the code, but don't shy away from documenting clearly and completely when necessary.

Of course, under certain circumstances, documentation may be required for reasons other than 'explaining what the code is doing' (eg: large team base, organization standards, and so on so forth).


答:
This is always going to be about cost. A new developer is going to cost them in salary, benefits, resources and probably training (at least training towards the business's model). Since you only list that you're working 50 or so hours/week and would like to see a more directed software production policy, a new hire is just flat out not going to be a reasonable prospect (business-wise).

You might have more success attempting to recruit from within. It's obvious that your boss/supervisor needs to be in on the process and should be aware that you feel you're being stretched thin and could use some support. It would not hurt to find someone within the company similar to yourself who is looking for a new challenge or a change towards this kind of task. Ask your supervisor to help lead an effort where this person's responsibilities can be stretched or altered to provide you with assistance. Gradually this can be increased over time until that person is completely working in tandem with you are (basically a transition similar to your own).

It's always a bad idea to throw too big a number (which a FTE amounts to from a business perspective). It sounds to me as if you do not work in an industry that produces software but that your company produces software to help support its business. So in any situation where you feel management needs to open the wallet even a little bit, you'll need to make it very attractive to the business. Big spends need to have immediate or large payoffs. Little spends are easier to get through the cracks and ultimately achieve the effect of a big spend through attrition.


答:
Do a small but valid cost-benefit calculation of hiring another junior, mid-level, and senior programmer.  Note that you must include that the more tiered you are, the more mistakes you will makes therefore the less productive you will be.  But fundamentally, it all comes down to costs -- perceived and actual. </p>

<p>Note that cost is not only money but quality of code, early bug resolutions, and quality of life. </p>

Body:
Do a small but valid cost-benefit calculation of hiring another junior, mid-level, and senior programmer.  Note that you must include that the more tiered you are, the more mistakes you will makes therefore the less productive you will be.  But fundamentally, it all comes down to costs -- perceived and actual.

Note that cost is not only money but quality of code, early bug resolutions, and quality of life.


答: I've been in a similar boat. A very similar boat. The one thing that really helped me make the "we need to expand the team" argument stick was how high our bus factor was -- if I got hit by one, there was no one who had any clue about the entire stack we relied upon. Getting someone else on the team was crucial for operations if nothing else.</p>


问:
How to translate a German Desktop App into English one
I am working on a desktop application which is in German. And this isn't comfortable for me to see the words and go to Google translate to translate it.

So I am looking to make extra effort for myself to try to translate the App into English using Google translate web service. But the Application doesn't use a Spring or AOP in order to make a single point of calling the web service.

My question is there a way to create a new project to introduce spring with AOP in order to achieve this.

or there is another way to achieve this ?

答:
I think what you should do depends a lot on the application itself and the business’ plans with it. If the application is only targetted for the German market, and the business does not plan to include localization, then you shouldn’t really localize it for yourself just so you can use it easier. If a localization is however planned anyway, it might be a good idea to involve the rest of the team with the process and make an actual localization system that works for everyone and isn’t just some “workaround”.

In case you do go with a localization and that solution is not only for yourself, I would not advise you to use Google Translate for it. Hire someone to do the translation, or at least let one do it who understands both German and English good enough. Being German myself, I can say that translation of German using Google Translate won’t work well – especially if you are using some German technical terms.

However again, if you are just planning a translation so you alone can work easier with it, don’t do it (YAGNI). Instead just keep continue using the program and eventually you will learn the program and those German terms good enough to be able to work with it smoothly.


问:
Is it better to use pre-existing bad practices, or good practices that don't fit well with old code?
I was thinking of this because I was trying to write an extension for an existing 3rd party software, and their database is horribly denormalized. I needed to use their existing tables and add a bunch of new fields.

I had the option of either creating new tables in their design style (which consists of almost all the propeties being in one big table), or creating a new set of tables alltogether and using something extra such as Triggers to synchronize data between the new and old tables.

I ended up going with the first option of using the existing poor design style, but I was left with this question: Is it better to go with pre-existing bad practices, or to implement good practices that do not play nicely with existing code? Is there some situations where I should choose one over the other?

NOTE: Many answers so far have to do with slowly refactoring the bad code, however I am unable to do that. The code is not ours, and it frequently gets updated by the vendor. I can only build onto it.

答:
In the long run, it is better to use good practices. It will save time and effort as changes will take less time to implement.

If possible, take little steps to refactor to good practice (for example: in SQL that would be breaking denoramlized tables to normalized one and using views with the old table names).

You will note that I said in the long run - the "quality, time, money" triangle applies here as well (i.e - choose two). If you don't have the time you may have to go with old practices, but this will mean that you are adding to the problem and that your design will also need to be fixed.

If you keep working and adding code of bad design, you will never end up with a codebase that uses good design. As much as possible try to use good design and refactor to good design.


答:
You could try to sell bringing in a contractor to do this project.  Sometimes it is easier to sell a short term solution then if it works out well and you can demonstrate the need it could transform into a full time position.

The best way to sell it is by selling the new solution as something that will save the company money.  You will need to estimate how long it will take and do not try to be too agressive here.  You might also find a list of the would be nice to do projects that you do not have time to accomplish now.


问:
Is there really a relationship between number of people assigned to a project and the number of defects?
Here is a quote from a training manual at work regarding SLIM and software estimation:

Notice also, there is a correlation between Effort and Defects. This means, the more people there are assigned to a project of a given size, the more Defects there will be.

Effort is person-time (person-years, person-months) for the project. Defects is the count of defects detected at any point in the lifecycle. Size is defined as the use cases, function points, or SLOC that compose the project.

This seems counterintuitive, assuming a good process and capable engineers. For example, having more people means more eyes on all of the artifacts (requirements specs, designs, code, tests). Aside from having more eyes, my intuition suggests that there is little relationship between effort and defects on a project that utilizes appropriate quality techniques.

I haven't been able to find any documents, aside from those about the Putnam Model (which is used by SLIM), that suggest any kind of known relationship between defects and effort or defects and number of people on a project. Is this a known relationship, and is the assertion that "more people = more defects" valid?

答:
Let's put aside the assertion about the number of people for a moment.

Looking at the number of defects injected as a function of effort might make sense as long as you assume that increased effort necessarily requires increased size, as there is a strong correlation between the number of defects and software size.

So if you assume that the more effort that is put into a project, the more lines of code are written, then you could probably use effort as a proxy for size to predict the number of defects.  Correlation between size (e.g. LOC) and the number of defects has been shown time and again in work by Watts Humphrey, Capers Jones, and others.

I don't see how the number of people fits, other than more people implies more effort.

As a side note, don't confuse correlation with causality.  While there is a correlation between size and the number of injected defects, size is not the cause.  The cause usually comes from, as you've pointed out, people and process issues.  That said, defects as a function of size is a great metric for understanding if there is a problem and for gauging the effectiveness of change.


答:
I'm assuming this is limited to members of the core programming team and not a situation where there are specialists like: UI, UX, DBA, etc.

I think it needs to be managed well, but that's not easy. Small teams made up of quality developers can manage themselves. It's more likely to avoid large sections of code created someone with less talent.

Having more team members can make it easier to divide duties. Put the better or more experienced devlopers on the difficult areas. Take away some of the mundane or non-programming tasks away from your better developers and let the junior devs handle the interuptions. This is going to take more planning and thought, but provides an opportunity to leverage your talent.

There's the notion that it's better to have a great developer who needs to pick up on a new skill than a below-average dev who already knows it. This is great if you have the time. Probably the reason more develpers are being assigned to a project is because of the amount of work required and the time limts. You may have someone who can focus on a specific area and become more skilled. It's great to have that well-rounded knowledge, but sometimes with a little direction, a lesser dev can take some instruction and run with it.

The reality is, there aren't a lot of people who have ever managed a large team on a successful project. Even if they are all talented, it's difficult for large teams to self-manage. Do egos get in the way?

Title: Is there really a relationship between number of people assigned to a project and the number of defects?

Body:
Here is a quote from a training manual at work regarding SLIM and software estimation:

Notice also, there is a correlation between Effort and Defects. This means, the more people there are assigned to a project of a given size, the more Defects there will be.

Effort is person-time (person-years, person-months) for the project. Defects is the count of defects detected at any point in the lifecycle. Size is defined as the use cases, function points, or SLOC that compose the project.

This seems counterintuitive, assuming a good process and capable engineers. For example, having more people means more eyes on all of the artifacts (requirements specs, designs, code, tests). Aside from having more eyes, my intuition suggests that there is little relationship between effort and defects on a project that utilizes appropriate quality techniques.

I haven't been able to find any documents, aside from those about the Putnam Model (which is used by SLIM), that suggest any kind of known relationship between defects and effort or defects and number of people on a project. Is this a known relationship, and is the assertion that "more people = more defects" valid?


问:
Using Jython and Tomcat in bundle - should we even try to?
Have you ever used Jython in bundle with tomcat in any serious, production-ready service?

What pros and cons can you name?
Is it worth trying if all guys in team has no problems with coding on Java, but know python as well?

答: You can also look into scala if you decide to remain close to java world and looking for something different. Its compatible with java. I have found it a very good language to work with. It also has  web framework called liftweb.</p>


答:
You are dealing with technical debt here. In short, technical debt imply interest, that you have to pay over time, and at some point, you have to refund it.

Develloper's time cost money, so the technical debt can be seen just like the real debt, and cost real money.

You have basically two main solutions, and many solutions in between. You can decide that you don't want to refund that debt now, and continue to pay interest. Obviously, this will cost more in the long run, but allow you to have result right now. You can also choose to refund that debt, so you'll not go forward anymore as long as you don't refund it, but, at the end, you are free from interest.

Usually you have deadlines for delivery, and missing a deadline will cause distrust of your customer, and eventually you'll loose it. This could be a valid reason to burrow technical debt : you consider that what you gain with the customer worth the extra exepense of technocal debt.

You know that at the end, you have to adopt the new methodology, otherwize, you'll get more and more debt and you eventually go bankrupt (you now, when people decide to start again from scratch or when the project fail badly).

You have to plan how you'll change the existing codebase and transition to new practice over time, and distibute the change bit by bit on a daily basis. At some point, when thoses refactoring will leads to other losses, consider which loss is the worse and go for the best one.

The cost of not refactoring will increase over time (this are interests of technocal debt). So this will become eventually the costliest choice.

Be sure that your boss understand the concept of technical debt. Even with precaution, you will create technical debt. At some point, money as to be used to refund it. When you create technical debt on purpose, you HAVE TO have a valid reason for it, and see the debt as an investment (just like real debt). In any other cases, just DON'T DO technical debt on purpose.

You may be interested on methodologies to evolve DB and deploy thoses evolutions : http://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

By the way, that's a difficult task, so good luck. It worth it !

Title: Is it better to use pre-existing bad practices, or good practices that don't fit well with old code?

Body:
I was thinking of this because I was trying to write an extension for an existing 3rd party software, and their database is horribly denormalized. I needed to use their existing tables and add a bunch of new fields.

I had the option of either creating new tables in their design style (which consists of almost all the propeties being in one big table), or creating a new set of tables alltogether and using something extra such as Triggers to synchronize data between the new and old tables.

I ended up going with the first option of using the existing poor design style, but I was left with this question: Is it better to go with pre-existing bad practices, or to implement good practices that do not play nicely with existing code? Is there some situations where I should choose one over the other?

NOTE: Many answers so far have to do with slowly refactoring the bad code, however I am unable to do that. The code is not ours, and it frequently gets updated by the vendor. I can only build onto it.


答:
Well, I think it very much depends on each case. If performance and design permits it, it is better to use good practices. But if for instance, if that table is a high access table, then creating a trigger for sincronization might have a negative impact on performance.

Now, your client wont see that you used a better design, he'll just see that your solution made his system slower. This type of decision should be made in a case by case basis, and you should use your experience and criteria to decide.

I think you probably made the right choice.


答:
As much as possible, you should isolate your application code from the poor data design.

Are you updating their tables?  If not, then create SQL views to present those tables in a manner convenient to your application.  SQL views are relatively easy to write, and far easier to test than application code.

If you do have to update the legacy tables, consider writing stored procedures to manage the updates.  They are a bit more complex to write, but they can be tested instantaneously.


问:
Using a SDK with crazy code
I recently had to work with an SDK that had a lot of crazy parts*. Not using the SDK was not an option as it had to talk to some third party software.

What is the best way to deal with the crazy code? I genrally used static methods to convert between sensible data types to the format they required (ie bool to yesNo). That method did however lead to lots of calls to very unintuative static methods (which one of the three dateToString methods should be called where?)

Would a better approach be to store almost everything as a string in the database? Or possibly convert each datatype inline so its clear (although with repeated code). Possibly there is some more elegent solution I hadent thought of?

*Certain methods required an enum called yesNo which contained "Yes","y","No" and "n". There were also multiple diffrent formats of string they wanted to represent datetimes used inconsistently. There were also other smaller bits of crazy code.

答:
Given the nature of the issue, I'd consider Anti Corruption Layer.

...it is likely that... you are inevitably faced with the task of interacting with the spaghetti that is already there. Enter the Anti-Corruption Layer. (Anatomy of an Anti-Corruption Layer, Part 1)

Title: Using a SDK with crazy code


答:
To keep the old code in sync when you normalize a database with triggers ia a good solution if it is temporary. The goal should be to change the old code, but when dealing with a third-party, that may not work out. You'll have to stay on top of their schema changes.

Piling more and more features on the bad code is going to create continuous problems. Work-arounds become the norm. Users will become frustrated because changes are going to take too long and probably introduce other bugs or limitations. Who wants to be the programmer to say we can't do that instead of we shouldn't do that?

Some code can be left alone; we don't always have that luxury.


问:
Methodologies/tools for when developing on your own
Suppose you have to develop a medium+ sized software, fully on your own. Like if it was a personal project you want to accomplish.

What methodologies/tools would you use to define what needs to be developed, learned and have a global idea of what the system is as well in its details?

Basically to keep yourself in track and not get lost on the way.

答:
It depends on how you can distinguish and handle different tasks, because you'll need to take a look at every single step of the development process.

I think tools are only useful if you already know how to use them and one of the worst mistakes is learning how a tool works rather than learning what to do with it.

First, in my opinion, you have to write down what you expect the software will do and specially what it won't do. That's a crucial point. The next step is divide the final system into lower subsystems, making the building process easier. And last but not least you'll need to choose your tools. Basically a good IDE, a VCS and a data modeler. You can add a lot of other tools to help, but take care not to start on the wrong track.

Well, the beginning seems not so attractive, but the process will become fun along the time.


答:
You should choose better design if:

You are going to be taking over a large part of future coding

Better design isn't more expensive to the client in the long run. For instance, I have witnessed multi-month "refactorings" for projects that were discontinued by the end of the year.

You should choose "same bad style" if:

You're just helping out. It's unrealistic to think you can take an existing group and will them to higher design standards if you're just a part-time fill-in on the project.  Better design is subjective and almost always has a learning curve. If that new design isn't learned by the rest of the team then the project will end up with a mish-mash of styles, and your better designed code may end up in the pile of stuff that nobody changes because they can't understand it. In your example above, what happens if there are updates to the third party software?

Sacrificing "better" design will get you a tangible business advantage. Like adding feature X badly will get you a large contract, but missing the deadline causes you to end up with nothing. This is where the historic conflict between mgmt and the technical team come in. Like renovating a house, someone has to decide when to pay. You can pay down the debt initially by living with no electricity or plumbing for a year. Or you can pay 3x as much with the benefit of having those utilities.


问:
Why isn't functional programming more popular in the industry? Does it catch on now?
During my four years at university we have been using much functional programming in several functional programming languages. But I have also used much object oriented programming to, and in fact I use object oriented languages more when doing my own small project to prepare for my first job. But I often wish that I was coding in a functional programming language when doing these projects.

However, when looking for a job, it is very rare to see a job where knowledge of a functional programming language is required.

Why isn't functional programming languages used more in the industry? There is quite much news about functional programming languages these days, so I wonder if functional programming is catching on in the industry now?

答:
This question have slightly wrong premise. For the following reasons:

Functional programming is actually pretty common in the industry. But it's only used where experienced programmers are available. Beginners cannot be expected to know it. Almost all large programming projects are using it, but they just keep it in areas which are handled by experienced programmers. Beginners will deal with the easy modules which do not require functional programming.

Given this reality, companies that are hiring people (usually young ones coming from university) cannot really ask for functional programming experience. Anyone in projects which requires functional programming has already been in the same company for 15 years.

Universities are starting to teach it, because they know already now that functional programming knowledge will be very useful in 30 years. Their time range is in 30 years, not the normal half year like in companies.

These points are the reason why people get disappointed when they enter the work force and see that the stuff they learned in university are not used. But they were designed for 30 year timespan, and it will be useful eventually -- it's just that companies are using the simple stuff - the stuff they can expect people to know.

Also you would be arrogant if you think after few years of university, you know functional programming well enough to use it in actual software projects. Start from the simple stuff first. You don't really need to do the most complex piece of software as your first task when you start working. You'll eventually get to the complex stuff, but it takes time.


答:
The real problem is state.

Functional languages don't have global state. Most industrial problems require state at the large scale (how do you represent a ledger or a set of transaction) even if some functions at the small scale do not actually require it (processing a ledger).

But we are running code on Von-Neuman architecture machines which are inherently state-full. So we have not actually got rid of state, the functional languages just hide the complexity of state from the developer. This means that language/compiler has to deal with state behind the scenes and managing it.

So though functional languages have no global state, their state information is passed as parameters and result.

So the question then becomes can the language handle the state efficiently behind the sense? Especially when the data size far exceeds the size of the architecture.

Looking at it from Hardware Side

The OS has helped a lot in the last couple of years in visualizing address space so applications do not officially need to worry about it. But applications that do not worry about fall into the trap of thrashing the hardware when memory pressure becomes intense (thrashing hardware will slow your processes to a crawl).

As the programmer has not direct control over state in the functional language they must rely on the compiler to handle this and I have not seen functional languages that handle this well.

On the converse side of the coin the state-full programmer has direct control over state and can thus compensate for low memory conditions. Though I have not seen many programmers that are actually smart enough to do so.

Looking at from the industry side:

Industry has a lot of inefficient state-full programers.

But it is easy to measure improvements in these programs over time. You throw a team of developers at the problem they can improve the code by improving how the program handles state.

For functional programs the improvements are more difficult to measure as you need to improve the tools that will improve the programs (we are just looking at how applications handle underlying state efficiently here, not the overall improvement of the program).

So for industry I think it comes down to the ability to measure improvements in the code.

From a hiring perspective

There are a lot of stat-full programmers available for hire. Functional programers are hard to find. So your basic supply and demand model would kick in if industry swapped to functional style programing and that is not something they want to happen (programmers are expensive enough as it is).

Title: Why isn't functional programming more popular in the industry? Does it catch on now?

Body:
During my four years at university we have been using much functional programming in several functional programming languages. But I have also used much object oriented programming to, and in fact I use object oriented languages more when doing my own small project to prepare for my first job. But I often wish that I was coding in a functional programming language when doing these projects.

However, when looking for a job, it is very rare to see a job where knowledge of a functional programming language is required.

Why isn't functional programming languages used more in the industry? There is quite much news about functional programming languages these days, so I wonder if functional programming is catching on in the industry now?


问:
Open Source Friendly IP Contracts for Freelancers
I am about to enter the world of consulting for the first time and am having to write my first contract. One problem I have is regarding open source work and intellectual property. I love working on open source projects, whether it's an existing project or a project that I start on my own.

The question is: how can I write my contract to accommodate the following situations:

In the course of working on the client's project, I want to open source part of the code to the community under my own name.

In the course of working on the client's project, I am making use of some of my existing open source projects, and am making improvements to them.

In the course of working on the client's projects, I make improvements to third party open source projects and contribute them back.

In the course of working on the client's project, we decide to open source part of the code under the client's name.

What are the precedents to this if any?

Update: I added a item in the list above(item #3).

答:
As well, IANAL - so I'd recommend consulting with an attorney that specifically understands or specializes in software intellectual property issues.

But, I think the answer is fairly straightforward:
1.  I don't think there is any need to discuss the term "open source" with the client (read forward before forming an opinion on that statement)
2.  In your contract, you clearly need to state the following:
    a.  Any work you create for the client you JOINTLY OWN and each can create derivative work products.  This means you each can use it as you see fit, including contributing to an open source project (consult the open source project's IP requirements of course).
    b.  You retain ownership of any pre-existing work product that you are nice enough to include for free, and you issue an unrestricted license to your client to use that code in perpetuity, including the creation of derivative works
    c.  Any third party code or products used are owned by their respective owners, and are subject to their licensing

You'll also want to make DAMN SURE that you don't ever ever ever sign any contracts with an Assignment of Inventions clause that isn't extremely limited (they never are) - or you may be legally SOL.  Note that there are several states (i.e. California) that limits (but doesn't eliminate) this by law regardless of what the contract says.  This is expected in an employment contract (but limits may be able to be negotiated), but IMHO should not be granted for an independent contractor contract.

Your biggest challenge will be getting them to accept joint ownership of the source code.  This conflicts with the "Work made for hire" doctrine that is specific language that is very often used in software development contracts when using contractors.

If they understand IP, they may not agree to this - but I'm guessing that those aren't the type of clients you're dealing with.  I can tell you with certainty that there is at least one extremely large software company that does this for any consulting/custom code written for any client - and if they won't agree to that, then they won't do it - period (but they'll refer them to a partner).

If you have joint ownership you should be fine IP-wise to contribute that code to an open source project, subject to any restrictions made by that project.

You'll also want to be selective in what you open source.  You would be doing your client a disservice if you open sourced industry-specific code that would be useful to their direct competitors.  Your client will also be less than happy if they realize that the entire app that they paid you to custom write for them is available for free - and could even at first think that you just installed it instead of writing it from scratch.  You also just diminished their perceived value of your services.

I think this covers your questions 1,2, and 4.

Question 3 could be a problem - depending on the licensing model of the open source project from which you are creating a derivative work, the client can certainly pay you to do it, but they may not have complete or even any ownership of that code per the licensing model of the open source project.  That is not to say that you can't do it - but you may want to cover that with an additional clause in your contract - and run it by an IP attorney - or only do that after a client asks you to do this - and then you might be able to charge back the costs of having an attorney review an addendum to your contract covering this situation.


问:
Code maintenance: keeping a bad pattern when extending new code for being consistent, or not?
I have to extend an existing module of a project. I don't like the way it has been done (lots of anti-pattern involved, like copy/pasted code). I don't want to perform a complete refactor for many reasons.

Should I:

create new methods using existing
convention, even if I feel it wrong,
to avoid confusion for the next
maintainer and being consistent with
the code base?

or

try to use what I feel better even if
it is introducing another pattern in
the code ?

Precison edited after first answers:

The existing code is not a mess. It is easy to follow and understand. BUT it is introducing lots of boilerplate code that can be avoided with good design (resulting code might become harder to follow then). In my current case it's a good old JDBC (spring template inboard) DAO module, but I have already encounter this dilemma and I'm seeking for other dev feedback.

I don't want to refactor because I don't have time. And even with time it will be hard to justify that a whole perfectly working module needs refactoring. Refactoring cost will be heavier than its benefits. Remember: code is not messy or over-complex. I can not extract few methods there and introduce an abstract class here. It is more a flaw in the design (result of extreme 'Keep It Stupid Simple' I think)

So the question can also be asked like that:

You, as developer, do you prefer to maintain easy stupid boring code OR to have some helpers that will do the stupid boring code at your place ?

Downside of the last possibility being that you'll have to learn some stuff and maybe you will have to maintain the easy stupid boring code too until a full refactoring is done)

答:
You, as developer, do you prefer to maintain easy stupid boring code OR to have some helpers that will do the stupid boring code at your place ?

I don't understand the revised question. I think most people, as myself, would prefer not to maintain "stupid boring code". I don't know what you mean by helper, sorry.

The poster answered their own question by not making big changes right now. Good choice. I have problems with a developer's arrogance that they know what's best for the business. A big refactoring on the sly... because you know better than your boss? Any capable manager can weigh up benefits.

If refactoring isn't an option then the question becomes more of a discussion about the correct time, place, etc... for doing it. Consistency is very important. Yet long lived code often benefits from "renewal". Others have discussed this...


答:
I believe there's only one real answer to your question.  You can get into a lot of related reasons why this answer is the case, but those are different questions.

Here it is:

Software architects provide solutions they are confident will work.

The majority of architects do not work in functional languages.

Once technologies and languages are chosen, businesses find people who can work with them.

Is it catching on?  That all depends upon whether people who are confident in using functional languages are becoming architects and choosing to use it for the projects they work on.


答:
Seriously, both of the answers began with IANAL - I think that you need to stop even thinking about writing a contract and talk to a lawyer before proceeding. You wouldn't ask your lawyer how to refactor parts of your code.

Also - @Pete Wilson is right, your stipulations are probably not going to go over well with your client.

Title: Open Source Friendly IP Contracts for Freelancers

Body:
I am about to enter the world of consulting for the first time and am having to write my first contract. One problem I have is regarding open source work and intellectual property. I love working on open source projects, whether it's an existing project or a project that I start on my own.

The question is: how can I write my contract to accommodate the following situations:

In the course of working on the client's project, I want to open source part of the code to the community under my own name.

In the course of working on the client's project, I am making use of some of my existing open source projects, and am making improvements to them.

In the course of working on the client's projects, I make improvements to third party open source projects and contribute them back.

In the course of working on the client's project, we decide to open source part of the code under the client's name.

What are the precedents to this if any?

Update: I added a item in the list above(item #3).


答: Be direct and don't worry about underselling yourself.  Instead, hope that a more senior programmer will get hired.  Its important that you are challenged by programmers that have more skill than you, especially in your first few years.


答:
Look into hiring a consultant...PM me, and I'll get the necessary paper work started :)

Seriously though, maybe someone could come in 20 hours a week and work on the code with you, you'd probably benefit also from having someone more "advanced" coding next to you.

You get all this with none of the risk of hiring someone.


答:
Given the recently updated definitions of size and effort, I would suggest that perhaps the results are due to the fact that Effort (total man-hours) is actually a better estimator of true project size than the measures the source is using (Effort would be a perfect measure if all teams and team's resources were equivalent).

Therefore what is really happening is that larger projects have more defects, which is not surprising at all.


问:
Do GUI programmers have an undue advantage over others?
It is easy for managers and customers to appreciate what they can see.

I have seen many GUI developers who are average programmers with minimal knowledge of design principles or other programming idioms. However, these shortcomings often go unnoticed, specially by management and customers, if the programmer can create an impressive looking user interface. So much so that many GUI developers I know spend hours beautifying the GUI at the expense of writing bad, unmaintainable code.

On the other hand, middle tier programmers who develop APIs or business functionality or database code (SQLs etc.) are at a disadvantage as there is nothing tangible to showcase. Perhaps a code reviewer or an architect may appreciate the elegance, good design, scalability etc. of code but it means nothing to the outside world. Your code may run for years without breaking, may be very easy to maintain and have good performance, yet it never elicits the 'wow' that a slick looking GUI does.

In my opinion, a corollary to this is (and I am going to get heavily downvoted for this, I know) that there is less motivation for a GUI programmer to write good clean code.

EDIT: I must explain here that by GUI programmer, I don't mean a full-fledged web/GUI designer but a front-end programmer e.g., a java-swing programmer.

Does the rest of the community agree ?

答:
To (maybe) expand a little on @TheLQ's answer, I think it also depends on the "viewer".

I've had some experience with a few upper level managers/supervisors that don't have a programming background. Some appreciate that they don't program, but understand that chrome and hubcaps are just as important as the engine and chassis.

And I've had experience with some upper level managers/supervisors that don't care about any metrics other than the UI sizzle. Even stating that more UI oriented developers where important.

IMHO, we all know that you can't polish a turd and a fast, reliable yet ugly app will far worse than an app that both looks good and functions good. It's all in the eye of beholder and to an extent, you have the power (regardless of what you do) to be seen in the light you want, by working for those that appreciate the same qualities as you.

EDIT:
I might add, being someone who feels more comfortable working on lower-level items, I have been jaded when you work equally as hard as the UI team and it's the polish that's lauded in the demo and not the fact that the system "just worked". But like I said, I know that my supervisor's know the work is needed on all areas.


问:
What metrics do you use on your Scrum project?
We are starting a new project and the board/stakeholders are asking for metrics to check the team performance.

As a junior ScrumMaster I told them:

about the Velocity and BurndownChart

that we can chose any type of metrics as long as they are team based and not individual, they do not push people to act awkwardly / counter productive (as you get what you reward)

Is there any other thing I can provide them in this regards? Have you got metrics other than velocity?

答:
Velocity is a poor metric for use by anyone outside the scrum team, because a story point is not a fixed unit.  It's useful for estimating how much you can take on in the next sprint, and for calculating burndown, but if team members are chided for a low velocity, they will just make their story point estimates higher.  Even if you're not trying to manipulate it, velocity can vary significantly for a host of other reasons, such as uncertainty, estimating skills improving over time, or estimating skills decreasing temporarily when working with unfamiliar technology.

In my opinion, burndown should be all they need.  What better metric is there than to know if your team is on track to deliver the features the business values most, by the time those features are expected?  They also have the opportunity to sit down with you every sprint and have those features demonstrated to them in person.  If quality is starting to suffer, they will know it then if they take the demo seriously.

Remember, part of the agile manifesto is "Customer collaboration over contract negotiation."  If you're doing it right, they won't need as many raw numbers to evaluate your performance, because they can evaluate your progress with their own eyes.


答:
This is a typical problem of: "Do I need to reap the benefits of my work now or later?" and I don't think there can ever be a generic solution to that answer. Only you know all the factors (technical and human) involved in such a decision.

However your problem raises an interesting question:

Is automatic code refactoring making enough advances so that code uniformity should be valued more?

Ultimately, bad design should change or die. Or else, it's not a bad design. The real question here is about the cost of refactoring. It seems clear from your question that you (or your employer) is not willing to pay the price now, and in the current state of technology, is not likely to ever want to.

However, code refactoring automation is making some advances. If compilers can optimize binaries today, who's to say they wouldn't optimize code tomorrow? At some point, some tool is going to come up, allowing developers and designers to refactor their code very easily, in order to adapt to newer requirements. After all, dealing with legacy code is one of today's biggest challenges.

If such a tool ever exists (I wouldn't be surprised that it already does), it would be good to take it into account, when making such a decision.


问:
Integrating Domain Model Applications - Resources/Guidance
I'm struggling to find guidance on integrating various applications, usually based on a Domain Model architecture. The applications often expose and consume each others WCF services, but this tends to be done in a rather hap-hazard way. I'm quite certain that the domain should not access another applications services, but where should they be consumed from? UI, Application layer? Data Layer? All I've read about SOA seems to contain theoretical information about what makes a service, but nothing about how to actually implement it in code. And what if I need to  return/query on a join between two entities in two systems? Many resources suggest denormalising data into the calling system, and updating using messages, but should messaging and WCF be combined in the same system?

I've read Enterprise Application Integration but it still leaves me with many questions. What are good resources/code samples for integrating domain model systems?

答:
There is no problem that cannot be solved by adding a layer of abstraction, except for having too many layers of abstraction.

If you have four domains from four disparate apps, and you are attempting to integrate their functionality or data into one app, then use the four domains, with an extra layer on top to handle interop between them; each domain or SOA layer will talk to your new layer, which will facilitate passing data across the borders of each domain as well as up to the application, so the domains can remain unaware of each other as they are in their original apps, and the application layer has one point of contact so it doesn't care how many separate domains lie underneath. Exactly how you architect this is dependent on the nature of the domains and SOAs you are integrating.

If you think of your app in an n-tier fashion, e.g. UI/Application/Domain/DAL/Data, and don't want to think of this new layer of abstraction being its own tier, then consider it as part of the Application layer. However, it is usually best explained as a new tier, "Interop", between Application and Domain layers.

Do be aware of the exception to the rule in the first sentence. Avoid architecting "lasagna code", having so many layers of abstraction between tiers that even simple changes like adding a field require you to spend your day drilling down through all the layers of abstraction. Data, mapping, domain field, service layer (client and server), DTO, application layer, Controller, UI... You could easily end up touching a dozen objects just to add a checkbox to a form if you over-separate. Also avoid the "God Object" when implementing your interop layer; it can be tempting to create one object that can give any object to any other object, but consider Factories and Converters with smaller scopes that are managed by supervisor objects (again, no problem you can't solve with another layer of abstraction...).


问:
Software Manual - Where to start
Are there any software packages out there for generating a nice looking users manual for small projects?  I'm not talking about source documentation.  I want to create an end users manual that doesn't look like I spent 20 mins in Microsoft Word.  </p>

答: Yes, there are dozens.  You're looking for whats called 'Help Authoring' tools.  Many will let you output the content as both a help file and a manual.  I'm particularly fond of Help and Manual, but there's quite a few others.</p>

Title: Software Manual - Where to start


问:
What does SVN do better than Git?
No question that the majority of debates over programmer tools distill to either personal choice (by the user) or design emphasis, that is, optimizing design according to particular uses cases (by the tool builder). Text editors are probably the most prominent example--a coder who works on Windows at work and codes in Haskell on the Mac at home, values cross-platform and compiler integration and so chooses Emacs over TextMate, etc.

It's less common that a newly introduced technology is genuinely, demonstrably superior to the extant options.

Is this in fact the case with version-control systems (VCS), in particular, centralized VCS (CVS and SVN) versus distributed VCS (Git and Mercurial)?

I used SVN for about five years, and SVN is currently used where I work. A little less than three years ago, I switched to Git (and GitHub) for all of my personal projects.

I can think of a number of advantages of Git over Subversion (and which for the most part abstract to advantages of distributed over centralized VCS), but I cannot think of one contra example--some task (that's relevant and arises in a programmers usual workflow) that Subversion does better than Git.

The only conclusion I have drawn from this is that I don't have any data--not that Git is better, etc.

My guess is that such counter-examples exist, hence this question.

答:
There are two major trends in version control right now; Distribution, and Integration.

Git is great at decentralization.

SVN has lots of tools built that integrate with it. It's common to set up your SVN server so that when you check in a fix, you mention the bug number in the checkin comment, and it automatically sets that but to an "in testing" state, and alerts the assigned tester that they need to look at it. Then you can tag a release and get a list of all the bugs fixed in this release.

The tools that do this with SVN are mature, and used every day.

Title: What does SVN do better than Git?


问:
JavaScript and the paradigm shift in web programming
If my memory serves me right, there was a time when using JavaScript for web development was hugely frowned upon, because among other things, it was a privacy and security concern for users and some people just had it off.

Nowadays, you can hardly see a major website that doesn't use JavaScript, and many websites will cease to function altogether without JS, graceful degradation be damned. Either that, or usability will be severely impacted, like on SE sites.

What has changed between then and now that made JavaScript practically ubiquitous in web development? Or is my assertion that JS was frowned upon a figment of my imagination and it has always been this way?

答:
Several changes came together to make thes brave new world:

Ajax Ok, lets be honest -- I mean Gmail. Gmail showed people that you could build a fluid web application in javascript. A flood of Ajax applications followed.

jQuery The browser's DOM APIs are horrible, and inconsistent to boot. jQuery gave people a decent API to code to that was consistent across browsers. (Yes, there are other good projects that do this to, but jQuery is the most popular.) It was also easy enough that non-programers could copy-paste their way to have smooth animation.

IE6 No, really! IE6 was the first browser to properly support something like the real CSS Spec, and the fact that IE was so dominant meant that you had a reliable baseline to build against. The fact that we laugh at it now has more to do with how old it is -- it was not bad when it first came out.

Chrome When Google came out with chrome, and its fast V8 engine, they started a new performance race, the outcome of which is significantly increased javascript speed across the web. Faster javascript means you can do more in javascript before it starts to annoy your users.


问:
What is the difference between 'layer of abstraction' and 'level of indirection'?
I am not sure if both terms can be used interchangeably. Maybe there is some academic distinction in computer science which is not relevant for day-to-day programming? Or can I use both term interchangeably without being wrong? Maybe it depends on the context in which I use both terms?

Edit: On reason why I find both terms possibly interchangeable is a Wikipedia entry about Abstraction layer. There you can find David Wheelers quote 'All problems in computer science can be solved by another level of indirection.'

答: My understanding is that abstraction mostly refers to functions and indirection mostly refers to data.  In other words, the level of abstraction is how deep your stack trace gets, and the level of indirection is how many pointers you have to dereference.  At least that's how I use the terms.</p>


问:
Is the JavaScript syntax the same for all browsers?
As for interacting with the DOM, different browsers will offer methods -and results- that are different between them to some or other extent.

But how about JavaScript itself? Do all browsers (or platforms e.g. Adobe Reader) implement the same syntax and behavior?

Aspects that particularly worry me are function/object handling and arithmetical operations.

答:
The JavaScript standards committee updates JavaScript annually. Browser Support Varies. Tooling is available to help.

Javascript is defined by the ECMA-262 standard, which is updated anually. Every revision has added some new syntax. All browsers since IE5 support a common subset of syntax in the same way, it's only a question of if they support new syntax options or not. However, since syntax extensions can be as small as Allowing trailing commas in parameter lists, it's not always obvious which options you are using. Here's a list of the changes since they went to annual updates.

It is common practice (in 2021,) to include a build step for your JavaScript that replaces newer syntax with older syntax so that code can be run in older browsers that are not updated. Babel, Browserslist, and @babel/preset-env make it easy to support a configurable set of browsers. (As long as you're still developing your site!)

ContentLicense: CC BY-SA 4.0


问:
How do I convince my employer to hire an additional developer without selling myself short?
I'm the only developer at a small company. I've slowly moved into development here; until ~4 months ago 50-75% of my time was spent on operations. Now, 50-75% of my time is spent on development, with the rest split between operations and various IT stuff. I regularly end up working 50+ hours a week.

I inherited some rather poorly-written applications (they were previously maintained by two people) that much of the business relies upon. Keeping these up and running, working on new, smaller applications, and my other responsibilities already take up all my time.

In order to be scalable, the existing software needs significant refactoring and additional functionality. I haven't had the pleasure to work on properly written or architected software before. The complexity of this task is well beyond anything I've done before (this is my first job out of college.) I know there's a feverish devotion to self-learning/learning by doing among many here, but this is so beyond my expertise that I wouldn't be doing my employer or myself any favors trying to tackle it alone.

I've been very direct about my inexperience, and in the past have mentioned that hiring another, more experienced developer will probably be necessary...if anything, just for the amount of time required for anyone to do the work as we grow and have more software to develop and maintain. I know that I would greatly benefit from hiring another developer; having someone to learn from and bounce ideas off of would be great. StackOverflow is great for determining approaches to individual coding problems or concepts, but is no replacement for discussions on a wider or more significant scale specific to a certain business domain. When mentioning hiring another developer in casual conversation recently, they didn't seem to think it was that important or necessary.

tl;dr: Current patch jobs and other responsibilities already take up all my time at work, work on existing applications that needs to be done is beyond my skillset, little chance of me having any time to work on new products that are being planned. Employer initially seems reluctant about hiring another developer.

How can I "sell" hiring another developer without sounding like I'm lazy or incompetent (I'd like to think I'm neither!)?

edit: Just wanted to clarify that I'm in no way interested in taking any kind of hostile action to prove a point (i.e. taking a vacation to show them they'd be screwed if I wasn't around.) I'm pretty content working here and consider myself to be fairly compensated, even figuring in the overtime, which is why I'm nowhere near considering a new job yet. That said, I accepted the 'no more overtime' answer - even if I don't mind working over too much I'm not doing anyone any favors by doing so (prone to more errors, wear myself out) and it's not really tenable in the short term much less the long term. I'll be stressing this when discussing the matter with my supervisor, and will probably suggest hiring a contractor part-time as an initial approach that's more financially palatable. Thanks for all the great answers.

答:
When it comes to asking for raises/bonuses, you have to put your worth to the company in the context of how much money they make as a result of your work and what someone with your ability can make in the current job market. In your case, you're looking to establish the value of software development and whether or not the money is there to hire another developer.

Start finding out the value of this work to the company. Information is power. I undersold a custom application I wrote for a company. I thought they were some small company owned company and gave them a break only to discover they were being bought out and the application help to legitimize them in their industry.


问:
What should I do if Scrum member leave half way?
Due to health condition of one of the scrum member, he has to leave the team.

My question is, do I need to start a sprint planning session again? or change the burn-down chart? or ask all the team members to bite the bullet and do extra work to meet the target?

Thanks

答:
You need to de-scope the least important stories and move them to the next sprint. Your capacity has changed and the sprint should reflect that.

If the customer adds a new, high priority big story, what do you do? Accept it and add it to the sprint? Re-plan? Change the burn-down chart? Bite the bullet? No. You de-scope other stories as you don't have capacity.

This is no different - the circumstances have changed and your team can no longer commit to the initial scope.


答:
My reasons:

maturity - both the server, and the tools (e.g. TortoiseSVN)

simplicity - less steps involved, a commit is a commit. DVCS such as Git and Mercurial involve commit, then push.

binary handling - SVN handles binary executables and images better than Git/Hg. Especially useful with .NET projects since I like to check build-related tools into source control.

numbering - SVN has a readable commit numbering scheme, using just digits - easier to track revision numbers. Git and Hg do this quite differently.

Title: What does SVN do better than Git?

Body:
No question that the majority of debates over programmer tools distill to either personal choice (by the user) or design emphasis, that is, optimizing design according to particular uses cases (by the tool builder). Text editors are probably the most prominent example--a coder who works on Windows at work and codes in Haskell on the Mac at home, values cross-platform and compiler integration and so chooses Emacs over TextMate, etc.

It's less common that a newly introduced technology is genuinely, demonstrably superior to the extant options.

Is this in fact the case with version-control systems (VCS), in particular, centralized VCS (CVS and SVN) versus distributed VCS (Git and Mercurial)?

I used SVN for about five years, and SVN is currently used where I work. A little less than three years ago, I switched to Git (and GitHub) for all of my personal projects.

I can think of a number of advantages of Git over Subversion (and which for the most part abstract to advantages of distributed over centralized VCS), but I cannot think of one contra example--some task (that's relevant and arises in a programmers usual workflow) that Subversion does better than Git.

The only conclusion I have drawn from this is that I don't have any data--not that Git is better, etc.

My guess is that such counter-examples exist, hence this question.


答:
No. You don't ask people to work extra hours. Do you want more to leave?

What is a burn-down chart? It's the graph of what points are completed against the graph of what points you need to complete before the deadline. So why change it? Keep graphing and you'll see the effect that losing a developer has and can keep the customer informed.

The customer can use that information to descope or extend the deadline. What they can't be allowed to do is say that they want more resources. Resources come when you find them and go when they feel like it and forcing in the wrong person quickly will not solve your problem. This is particularly true as the deadline approaches.

If you're going to hire someone, expect that to take time too, so the cost will be more than one developer's hours, and the gain will not be immediate.

Point out to the business that if they don't want this to happen in future, they need to hire too many resources at the start of the project and stay ahead of the expected requirement until close to the deadline (when, because they're ahead, they can lose half the team and not replace at a time when the remaining devs don't need to spend time training).

Disclaimer: All of this comes with the caveat, "in a perfect world." Now get as close to it as you can and you'll be ok.

Title: What should I do if Scrum member leave half way?

Body:
Due to health condition of one of the scrum member, he has to leave the team.

My question is, do I need to start a sprint planning session again? or change the burn-down chart? or ask all the team members to bite the bullet and do extra work to meet the target?

Thanks


答:
Abstractions are implemented using indirection.

For example, virtual memory: The abstraction is a contiguous address space entirely at your disposal. This abstraction is implemented using indirection via a page table. Instead of directly accessing physical memory addresses, they are translated from a virtual address to a physical address.

To add a layer of abstraction, you have to add a layer of indirection. But adding indirection doesn't necessarily give you an abstraction. For example, having getters and setters on every single variable is a layer of indirection, but if all they do is get and set simple values there is no abstraction.

Title: What is the difference between 'layer of abstraction' and 'level of indirection'?

Body:
I am not sure if both terms can be used interchangeably. Maybe there is some academic distinction in computer science which is not relevant for day-to-day programming? Or can I use both term interchangeably without being wrong? Maybe it depends on the context in which I use both terms?

Edit: On reason why I find both terms possibly interchangeable is a Wikipedia entry about Abstraction layer. There you can find David Wheelers quote 'All problems in computer science can be solved by another level of indirection.'


答: Do you havea a backlog of work you can't get to?  Make sure to reference that in talking to the boss as well. </p>


答:
First, lets try proper definitions for the terms:

Layer of abstraction means:

```<code> a) there is large number of positions which use abstraction
      (layer = all the positions together)
 b) each position is hiding some complex stuff, but allows invoking it
      using only simple code.
     (abstraction == one-to-one mapping between simple code and complex code)
</code>```

Level of indirection on the other hand means:

```<code>  a) you're counting levels
  b) indirection==there are several steps before you can reach or access the data
  c) level of indirection is just how many steps it takes to access the data
</code>```

Both of these things can mean the same thing, as long as you use:

```<code>  a) step = going from simple code to complex code.
</code>```

Body:
First, lets try proper definitions for the terms:

Layer of abstraction means:

 a) there is large number of positions which use abstraction
      (layer = all the positions together)
 b) each position is hiding some complex stuff, but allows invoking it
      using only simple code.
     (abstraction == one-to-one mapping between simple code and complex code)

Level of indirection on the other hand means:

  a) you're counting levels
  b) indirection==there are several steps before you can reach or access the data
  c) level of indirection is just how many steps it takes to access the data

Both of these things can mean the same thing, as long as you use:

  a) step = going from simple code to complex code.


问:
why use a form object when you can get needed data from view object's html?
I am working with server side code.

I have a request object that handles request data validation and filtering.

I have a view object that uses template files to generate html for output. the template files are mostly html. you can put one view object inside of another view object in order to assemble a page piece by peice. for instance you might have a page layout view, and you might put a form view inside the page layout view.

One of the features of the request object is that it can automatically build validations using an html5 string containing a form. It parses the html string and grabs input types and other tag attributes that determine HTML5 validation, then matches this validation server side. I get this html string from a view object. This way no matter what the designer puts in the view's template file, it will automatically get validated according to the html5 attributes server side.

i create and use the same view that was originally used to generate the page, to build validations for the request when the page is then submitted back to the server.

I would like to get feedback on this idea. Pros/Cons/Other Concerns.

答:
In the "other concerns" category, the first 4 words, "I'm building a framework" are actually a red flag.  "Framework" isn't well defined enough that I can be sure what you mean, but generally you want a library or toolkit more than a framework.  Framework usually implies that if you use it then you have to do everything within it, which means you can't also use someone else's framework,  or do things the framework wasn't designed for.  If so, it had better be a really good framework, which means it probably isn't worth the time to write it.

Of course what you are writing might even be more of a library than a framework, so it's just something to think about.

As for specifics, if your view object is on the server side and not coming from the browser it's not too bad, though then I really have no idea why it would be an HTML5 string (which I assume is a string that parses as valid HTML5?).  In that case, HTML5 is horrible to parse and apparently pointless, so you should send an object (like, the view object, perhaps).

I have no idea what you mean by the designer - is that a class or a human?

I think it's a human, in which case Demian Brecht has it quite right.  I suppose if the validation is in no way for security and you really don't care if users circumvent the validation rules then it isn't that bad, but you still have to parse HTML5.  In which case you'd better have a library handy - please oh please don't use regular expressions.  And it still might be harder than using a form - is there a reason you aren't using a form?

Also, think about how hard adding validation will be if you ever need something not addressed by HTML5.

You might get better answers if you explain why you are doing what you are doing (and are clearer about what).


问:
Selling a webapp: I don't want sell my source code!!! What do I sell so?

Possible Duplicate:

  Does making source code available affect your ability to generate revenue?

I'm developing a web application (it's not a website, it's a closed to public management application) and I'm really unsure about how should I sell it.

The application doesn't cost enough to allow me to ask this to a lawyer (he will asks maybe soemthing that is around the cost of the application), so I'm here to get some suggestions.

I would like to charge the client for the costs of developement (because the app is specialized on client requests), but I don't want to give them the source code, only the ability to use the application through web.

The second part of the problem is that I have to pay hosting for this webapp.
Because I don't want sell hosting service, and I don't want to allow them to access to my source code, I would like to address hosting service costs in my agreement as "upkeep costs" (so the client will pay me each year).

Is this a correct way to license a webapplication?Also, is this ethically correct? I mean, they won't have my source code and if they stop paying obviusly they can't use the application.

Any suggestion about different licensing?Should I sell my sourcecode when I build a website?

EDIT 1:

My fault, I wrote something wrong. I'm still writing the business plan so I'm definitely allowed to choose how to sell my app.

Also, because I'm paying some commercial licenses for a library that I'm using in the app, will this license belong to me? They are paying the source code, the license for the library is coming from my pocket.

EDIT 2:

I don't want to charge them for all development costs, client will not need to pay external commercial licenses, I would like to sell him only an application with a una-tantum fee (like when you buy World of warcraft, you pay for the game and then you have a recurring subscription) and then a subscription like SaaS. Is this possible?

Obviusly if I break the contract for some reason, they can take the source code.
If they stop paying me upkeep costs (hosting, but I want to use the hosting that I chosen), I can take down the application until they restart paying me.

EDIT 3:

To make clever what I would like to achieve: I would like to sell the app as I can sell a desktop app: I sell an executable file and not the whole code. Is up to me to charge it 1 or 100.
The problem with this approach is: if they pay the hosting service by themself and I upload the code there, they can obviusly see/steal my code. How can I solve this issue?

答:
Are you developing this for a specific client (sounds like it to me)? If so, you should have worked out the details before you started. If they're paying you for your work, then the source code belongs to them, plain and simple.

Easiest way to deal with the hosting issues is to have them set up a host account (with your direction) and simply give you the username and password. If things go south, they have control over the application that they purchased.

Another option (although this is something that should have been worked out prior to you starting work on it), could be to sell it as SaaS and charge a fee for it - most commonly as a subscription.


答:
If you want to charge them for all development costs, they should get ownership of the code (since they paid for the time to create it). And that's most common when you do consultancy or freelance for a given client.

If you want to keep ownership of the code, you'll have to either sell it as a product or as SaaS. In this scenario the return you get out of your product from 1 single client will (usually) be quite a bit lower than the costs to create the application. You'll need multiple (sometimes quite a lot) of clients to buy/pay for it to break even, even more to make profit.

Since the app is specialized on the client's request, this might be hard to realise.

Reply to your Edit 1:
How you handle the costs of a 3rd party library that you buy, is totally up to you, and might be coupled with how you plan to sell the rest (+ how the license of the library is defined).

How the license is defined:

License per developer machine: it's for your own machine, so theoretically you should pay for it.

License per production server: it's for their machines, the client pays.

Combination: just pick both above

Fixed price to use the library, no matter how many developers/production servers: it's up to you how you charge it. If you're going for selling as a product/SaaS, you'll have to cover the costs for the license yourself, and you own it. If you let the (only) client pay for all development costs, you can add the license costs as a part of the development costs and let the client pay for it. In this case they'll own the license and you're using it to create their product.

In the end it all comes down on the decision on how you'll sell the product/time spent. Either you do the work on their demand and to their wishes, and you charge the full 100% (or less if you cover slack/training/... yourself or if you want to give them a percentage to gain them as a good client). Or you go for a fixed price (close to the estimated costs + preferably some profit) which you decide upfront with the client. And you discuss who will own the sources (most likely they'll do).

Or you go the product/SaaS way and you charge the client way less. You make the application a bit more generic so it can be used by others too and you hope that it gets enough traction to sell to enough clients to make profit in the end.

Option 1 is the easiest and "guarantees" your money. Option 2 can be the way to get rich, if you hit a gold mine (e.g. the new facebook), but you can also spend all your savings on it and end up in selling only a few licenses, not covering all costs (+ future maintenance costs).

Edit 2:
I've got the feeling it always comes down to "I don't want that they steal the code". Whether you host it on a website or sell as a desktop app, just make sure all code is compiled (if needed with obfuscation if that makes you feel more comfortable). You might use a thin client (most logic on your server) as a desktop app, if you think that's better, I'm not sure what your application does and if that's a possible scenario.

If the program does what it has to do and the price is not extravagantly high, they won't bother opening up your assemblies to reverse engineer the code. I used to be afraid for my code too, but at some point you learn that most people won't bother to steal code since it costs more time to do so, than to just buy the app.
(And there will always be some people that look for cracks).

Just pick the scenario to sell your app that you're most comfortable with and go for it. As long as you don't give them the source files (uncompiled) on a plate, you'll be fine.

Title: Selling a webapp: I don't want sell my source code!!! What do I sell so?

Body:
Possible Duplicate:

  Does making source code available affect your ability to generate revenue?

I'm developing a web application (it's not a website, it's a closed to public management application) and I'm really unsure about how should I sell it.

The application doesn't cost enough to allow me to ask this to a lawyer (he will asks maybe soemthing that is around the cost of the application), so I'm here to get some suggestions.

I would like to charge the client for the costs of developement (because the app is specialized on client requests), but I don't want to give them the source code, only the ability to use the application through web.

The second part of the problem is that I have to pay hosting for this webapp.
Because I don't want sell hosting service, and I don't want to allow them to access to my source code, I would like to address hosting service costs in my agreement as "upkeep costs" (so the client will pay me each year).

Is this a correct way to license a webapplication?Also, is this ethically correct? I mean, they won't have my source code and if they stop paying obviusly they can't use the application.

Any suggestion about different licensing?Should I sell my sourcecode when I build a website?

EDIT 1:

My fault, I wrote something wrong. I'm still writing the business plan so I'm definitely allowed to choose how to sell my app.

Also, because I'm paying some commercial licenses for a library that I'm using in the app, will this license belong to me? They are paying the source code, the license for the library is coming from my pocket.

EDIT 2:

I don't want to charge them for all development costs, client will not need to pay external commercial licenses, I would like to sell him only an application with a una-tantum fee (like when you buy World of warcraft, you pay for the game and then you have a recurring subscription) and then a subscription like SaaS. Is this possible?

Obviusly if I break the contract for some reason, they can take the source code.
If they stop paying me upkeep costs (hosting, but I want to use the hosting that I chosen), I can take down the application until they restart paying me.

EDIT 3:

To make clever what I would like to achieve: I would like to sell the app as I can sell a desktop app: I sell an executable file and not the whole code. Is up to me to charge it 1 or 100.
The problem with this approach is: if they pay the hosting service by themself and I upload the code there, they can obviusly see/steal my code. How can I solve this issue?


问:
Refactoring or upgrading databases to handle new features
Several responses to a database schema question, suggested an additional table to normalize a database for a feature that is not part of the current requirements (A UserDepartment table to allow for a many-to-many relationship between employees/users and different departments they may belong to.).

Not against normalization. Seems like when it comes to database design, there is a strong push to include features that they're 'sure' someone will want in the future. Is it so difficult to add tables/fields to the database to accomodate features that there is a tendancy to over-engineer? Wouldn't they be refactored or upgraded just like the rest of the app if needed? Redoing things is never fun, but moving data from one table to a new one can be done. Just not sure where this line of thinking will end.

Edit: There is so much of an aversion to this, I wonder how many projects end up not adding a feature that requires a drastic database change or are non-normalized approaches taken like adding a DepartmentID2 field instead of a new table. The need for multiple departments for an employee is a common domain problem. I just haven't noticed many database schemas that are littered with many-to-many relationships.

答:
I usually explain it this way to the PHBs - code is the walls and roof, the database is the foundation.

Moving the walls and changing the roof can be done. Changing the foundation around requires a lot of digging and rebuilding the walls and roof.

What inexperienced developers (and college professors) say is "over engineering" is what experienced developers call "future proofing". Despite what the spec says you know what will probably change during the ALM or where the performance problems will occur so you want to get your table structure right to start with.

Rolling out update scripts to customer servers is a non-trivial project and each of the customers' DBAs are all over you wanting to the triple check it all. Some extra columns and tables aren't so bad after all.


答:
It's not unethical if you disclose you won't be giving your client the source code.  It is unethical not to let them get their data out if they discontinue though.

As far as legal stuff, IANAL, but the following is my understanding:  You are actually allowed to charge a client for all the costs of software development, SaaS fees, hosting fees, expenses (purchases of third part software, travel) and retain full ownership of the code.  Nor would your client automatically own the source code if you break the contract, more likely you would owe them damages, which might be limited to what they had paid you (or they might argue that the opportunity cost of not getting other software should be part of the damages, maybe, I don't know, IANAL).

However, there are some limits here.  Mostly, there is probably a point at which they will tell you no.  There is a legal concept of a contract so ridiculously one-sided that it isn't valid.  There is a legal concept of good faith, so if you had them pay the full development costs and then were unreasonable about the SaaS part - jacking up the price, making them jump through hoops, whatever, you might be in the same boat as if you had broken the contract.  Also, for some legal purposes it can be fuzzy if a client should be considered an employer, though you owning the software would be pretty strong evidence you are really an independent contractor or a separate business.  Probably not an issue, but I repeat, I Am Not A Lawyer.

As for making them pay for third party licenses, it is possible for them to pay and you to own them, if you both agree that's how it should work and the third party license also allows it.  That's the kind of thing you want to have in the contract.

I would think it might help legally if you at least gave them a discount on the SaaS in return for paying the development costs (if they are paying for those costs and getting nothing in return it's easier to argue they were supposed to get more, or that the contract is unfair - it sounds unfair).  I have heard of people giving the first client a small cut of future sales revenue (temporarily or permanently) as an incentive to let them retain ownership of the code.  If you do plan to sell the software to other people then giving your original client some incentive to help you build up more clients might not be a bad idea anyway.

Did I mention I'm not a lawyer?


答:
I post this as a response rather than a comment.

I admit than DVCS are quite in the trend right now, but I'll try to tell why.

DVCS are better because just like lots of people have been saying, "this is the way we should have been working from the beginning". It's true, you can do with a DVCS what you used to with SVN, so in a way that makes SVN obsolete.

However, not every software project is as good as it gets:

Long term project have a lot benefited from DVCS, because it uses less overhead, allows much better management (branching etc), and is greatly supported by hosts like google code and github.

Those projects are not the only ones, there are other kind of projects that are being developed in companies without any assistance from the outside world or internet: everything is done internally, and often on a short term. A good example: a video game. Code evolves rapidly.

For the latter case, developers don't really need branching or sophisticated features DVCS can offer, they just want to share source code and assets. The code they make is not likely to be reused, because there is a deadline. They rely on SVN rather than a DVCS because of several reasons:

Developers have machines that belong to the company, and this might change rapidly. Configuring a repo is a loss of time.

If those guys don't have their own machine, they are less likely to be working on the same source code/part of the project. Plus one for the centralized data.

network speeds and big money allows the use of a centralized server that deal with everything SVN, it's bad practice but backups are made etc.

SVN is just simpler to use, even if it's the wrong way: synchronizing files on peers without redundancy is not a simple problem, and "do it the right way" just cannot make it in time if you always want it to be perfect.

Think about the game industry machine and how SVN is a time saver; people communicates much more on those projects because games are about repetitive programming and adaptive code: there is nothing hard to code, but it has to be done the right way, ASAP. Programmers are hired, they code their part, compile it, test it a little, commit, done, game testers will deal with the rest.

DVCS are made for the internet and for very complex project. SVN are for small, short term, tight team projects. You don't need to learn a lot from SVN, it's almost a FTP with a dumb diff.

Title: What does SVN do better than Git?


答:
Is there any other thing I can provide them in this regards? Have you got metrics other than velocity?

Tests written/tests passed.

Both lines are (usually) non-decreasing.

The change in slope indicates a change in focus.  More tests should be written early in a sprint.  More tests should be passed in the middle of the sprint.  A few resist solving and last until close to the end.  Some never pass and are deferred.

When the number of tests rises late in a sprint it indicates things are being discovered.  Either user stories were incomplete (or misleading) or new technology (and new API's) are introducing new test scenarios.

Tests the persistently won't pass (or won't stay passed) indicate fragile code or a poorly-defined used case.

There's a lot that can be learned from the tests-written-tests-passed counts.

 [If you found this "dismissive" in any way, please flag it.  Apparently, my answers are "dismissive."  I've been warned and you should feel free to flag my dismissive answers.]

Title: What metrics do you use on your Scrum project?

Body:
We are starting a new project and the board/stakeholders are asking for metrics to check the team performance.

As a junior ScrumMaster I told them:

about the Velocity and BurndownChart

that we can chose any type of metrics as long as they are team based and not individual, they do not push people to act awkwardly / counter productive (as you get what you reward)

Is there any other thing I can provide them in this regards? Have you got metrics other than velocity?