Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Example: 2 of our top 3 users are working in almost equivalent projects (I don't know them in depth, maybe I'm wrong):
Marc Gravell's Protobuf-Net
Jon Skeet's DotNet-Protobuf
Jokes about Jon Skeet apart, and dreaming with an prideless ideal world (sorry guys, I am not accusing you of being arrogant, is a fact that every programmer must defend his own code), wouldn't it be a great opportunity to join efforts?
I am not saying that the community should decide what an individual must do, I just want you to raise pro and cons of merging projects, and what projects must have to be subject of such analysis.
Starting a new project without a thorough research of the available solutions and without taking into serious consideration the possibility to join an existing project, is something that the community should frown upon more emphatically. Maybe a programmer's education should include some discussion on the cost of effort duplication.
Having said that, experimenting with different approaches to solve the same problem is healthy, and once a programmer has some toy code, we should thank him for making it available to the public regardless of the existence of similar projects.
I think that the authors should seriously consider a merge if:
one design has proven clearly superior to the other
one community is being more active than the other
both projects share the same ideas on future directions
the work required to merge the two codebases is feasible
Merging should happen when it is overall beneficial. For example, if either or both of the projects:
Are too weak to survive on their own (not enough active development to keep up with technology changes); or...
Could provide good synergy through overlapping (i.e. not fully identical) functionalities.
However, there isn't anything wrong with having two strong projects that both do the same thing - it can help to encourage innovation as they try to be better than each other.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've recently attempted to start learning the C programming language, this question isn't specific to that one language though, or any language for that matter. I've found that I regret asking for information/best practices as early in the learning process as I have, simply because I'm receiving too much information.
As an example, I asked a question related to arrays in C:
Is defining the length of an array with a macro "excellent practice"?
What I found was, I received the answer I was looking for; but, I also received a slew of other information, that, as a beginner was absolutely over my head. I then regretted asking in the first place because I found myself worrying about things that I probably shouldn't know/care about at this stage in the learning process.
I guess what I'm asking is: do you think worrying about best practices and language caveats when I'm a beginner will be harmful to me, or is it encouraged? I find myself getting lost reading questions under the 'c' tag, of which I was trying to use to improve my knowledge, but now I'm bogged down and not making any real progress because of all the little details in comments/answers etc.
It's certainly not a bad thing, per se, as learning of advanced matters ahead of time can really help you along the road. This isn't even confined to computer science; I, for example, find myself in this position all the time when cooking a new dish or studying relatively advanced mathematics. Of course, if all the little details and super-technical stuff are stressing you out, by all means, take a step back and breathe, try and focus on the task at hand. You can always return to the more advanced topics later!
On the specific question of learning the standard practices and caveats of a given language, I personally recommend it. First of all, doing so can keep you from developing bad habits. Knowing the strengths and weaknesses of a given language are rather important, and can influence you later on. If you have one or two things you really hate about C, you can try another language in the future that addresses those issues. The sooner you acquaint yourself with such matters the sooner you can make a decision.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am a college student keen to improve my Programming skills. I have two pathways to follow:
Contributing to OpenSource Projects
Solving puzzles at codechef.com
Which one should I follow?
A good programmer is one who cares about his or her ACE - Accuracy, Clarity, Effectiveness.
A good programmer cares about the Accuracy of code. The easy part is coding the "happy path" because this is always in the forefront of our minds when we design and write the code. But what about potential the exception paths that exist when presented with unexpected input and edge case behaviours of the chosen implementation provided? Care is shown by taking the time to think through all the code paths, investing time in testing, submitting the code for peer review, and having the willingness to accept other's suggestions and make changes when appropriate.
A good programmer cares about the Clarity of code. Whether the code is well structured, expressive, adheres to the Open-Closed Principle, the Single Responsibility Principle, the executing machine doesn't care one bit. But, these are all very important to the next programmer, or yourself, who has to read and understand your code at a later date in order to fix bugs, modify behaviours, or add features.
A good programmer cares about the Effectiveness of code. Does it satisfy all the constraints imposed on it? Not only performance and space constraints, but also aspects that make it acceptable to the end user, the demands on the development and testing timelines by your clients, boss, family. Professional software development is not a precise circumscribed task, like "calculate the determinant of an NxN matrix". It has many constraints and demands, and good programmers are mindful of all of these, and will do their best to manage the them, especially when there is not enough time to satisfy all constraints completely.
So! To answer your immediate question, Open Source or codechef, I'd say that being involved in an Open Source project provides much greater opportunities to practice being a good software developer. So go choose an Open Source project that you care about, and ACE it!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
To me it seems that classroom training gives us building blocks of technique, but rarely covers actually building anything large or complex, and even when classroom training covers "large projects" you are still just graded on getting the correct end result.
Where should people turn to learn the larger aspects of software design? Specifically where can people go to learn actual "best practices" when starting to work on mid size to large projects/systems? (With less theory and more application)
(My focus would be on .NET and C#, but the question is valid for any technology)
Code complete - by Steve McConnell
Pragmatic programmer - by Andy Hunt and Dave Thomas
Facts and Fallacies of Software Engineering - by Robert Glass
In my experience, the only way to learn how to design and develop large projects is to work on such a project. This is inevitable when you consider that most large project problems are to do with communication - between team members and between code modules. This is something that is almost impossible to simulate in the classroom (I've tried).
One place: industry. This could be as an internship if you're still in college, or as a job if you're out of college. There's no place for you to learn the standard practices like at a company full of people developing software.
Code code code
Make mistakes, fix them
Ask for help - SO is great for that!
even when classroom training covers "large projects" you are still just graded on getting the correct end result.
You seem to be awfully concerned about how projects are graded. You shouldn't be.
Your grades are of course important, but they shouldn't be the end-all be-all of your university experience. You are there (presubably paying tens of thousands of dollars) to learn. Get your money's worth. Good grades should be a by product of the fact that you are learning the material well, not the other way around.
Your large projects in school will probably be your most important learning experience. Mine was where I first really came face to face with issues like:
The importance of design before coding
Communications between developers working the same project
Dealing with the very real differences in capabilities between developers
Dealing with the differences in motivation between developers
The nessecity of using revision control
Software integration
The whole experience ended up being a major topic in the job interview for the job I finally got after graduation.
I think we got a B on our project, but that was totally beside the point.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Background: There are a couple of concerns that are not core business for us. They are essential to our core business, but we have no business writing on our own, in terms of manpower, time, and expertise. I am familiar and very comfortable with some open-source implementations, using closed-source-friendly licenses, that could fill these gaps. Closed-source alternatives I either could not find, or were crap.
I put together an informal proposal to show my boss, including the original licenses for each project for legal review. Being a business owner that knows little about the world of open-source, he was initially hesitant when he realized some of these libraries were. I tried to educate him to the best of my abilities (I'm no open-source warrior myself), but he did bring up some valid questions that, in some cases, I don't feel I answered as well as I could have.
Concerns (worded from my boss's prospective)
How do we know and ensure there is no malicious code in an open-source project? Read and understand every line? At that point we could have just written it ourselves!
Who do we blame when things go wrong? With support licenses and a responsible party, we can get things fixed. And if they fail to come through, well... you know.
How do we establish or measure that an approach or implementation in an open-source project is sound, efficient, or good quality?
What sort of liability do we open ourselves up to, in terms of licensing [granted, this is more a question for lawyers and an issue of RFTL].
Question: How have or would you have addressed these concerns?
How do we know and ensure there is no malicious code in an open-source project? Read and understand every line? At that point we could have just written it ourselves!
Same problem with closed source. Actually worse with closed source. With open source at least you CAN review it yourself, or you can take someone else's word for it. With closed source, taking someone's word for it is your only option.
Who do we blame when things go wrong? With support licenses and a responsible party, we can get things fixed. And if they fail to come through, well... you know.
Probably the biggest issue. This depends on which particular solutions you're using. Some things are backed by a reputable vendor (e.g. Red Hat) whereas others have virtually no support. But that "you know" is critical here: ultimately there is no way to guarantee that someone will fix bugs that you encounter when you are using closed source. At least with open source you can hire a 3rd party consultant to do the job, for the right price, because you have the source.
How do we establish or measure that an approach or implementation in an open-source project is sound, efficient, or good quality?
The same way you would with any other code? I don't have any better answers for this one.
What sort of liability do we open ourselves up to, in terms of licensing [granted, this is more a question for lawyers and an issue of RFTL].
Yep, have a lawyer advise you on this. Every tech business should employ a lawyer anyway. The answer will depend on the specific licenses you're dealing with and what exactly you plan to do with the software you develop.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
This is not a question with a precise answer (strictly speaking the answer would be best captured by a poll, but that functionality is not available), but I am genuinely interested in the answer, so I will ask it anyway.
Over the course of your career, how much time have you spent on greenfield development compared with brownfield?
Over the last 10 years I would estimate that I have spent 20% on greenfield and 80% on brownfield. Is this typical?
I think it's typical for professionals who deal with customers to spend more time in brownfield development. The reason is that customers typically aren't willing to throw out their existing software to adopt the "latest and greatest" (green) software.
Developers in research or academics, however, may be more likely to do greenfield development. Start-ups as well.
I think that your ratio 20:80 is representative of many/most developers. As to new development: if you are building software incrementally (Scrum, XP, etc) then one could argue that you spend almost all of your time in brownfield development. Except for the initial iteration/exploratory work, prototyping, even when you are building something new, you are already working on an established code base, refactoring and extending. So how much greenfield development is actually green?
Often the problem doesn't just boil down to brownfield vs greenfield. In some cases there is a valid opportunity for a hybrid greenfield/brownfield approach.
I have written an article called "Classic software mistakes: To Greenfield or Refactor Legacy Code" which discusses this exact subject and outlines a range of possible combinations then evaluates the consequences of each.
http://stepaheadsoftware.blogspot.com.au/2012/09/greenfield-or-refactor-legacy-code-base.html
What may surprise some people is that a non technical attribute, company size, will be a big determinant in the choice of strategy and the likelihood of success of that strategy.
Over the past decade or so, I've always worked on software that was used as the center of my company's business. (Both SaaS and a software product.) And while I've always come into the with an existing system (so brownfield), we've usually put out a ground-up redesign/rewrite (so greenfield.) So, to break to down:
about 60/40 brown/green for the big projects, in number
about 20/80 brown/green for the big projects, in time spent on them
and nearly 0/100 brown green for little side projects
So, that is seems to be the opposite of you. It is the nature of the companies I've sought out, and hence the projects. My software is our company's main product, and that means I work on the same code base for years, usually after having created it from scratch myself/ourselves.
And I like it that way.