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 7 years ago.
Improve this question
As a passionate opensource developer, I produced a lot of software during the years. In some cases, this software became obsolete due to the fact that I moved to another project, and the platforms changed. I frankly don't have time to maintain my past projects anymore, and I don't have many chances to find a maintainer, as my projects are generally very sectorial in nature. In this sense, I expect them to die out of natural selection not only out of lack of personal involvement, but also because they are intrinsically less appealing to a larger audience that could spawn a maintainer.
In simple terms, my productivity does not scale up with respect to my past products.
Do you have any suggestions for this issue? Since "bit rotting" is so frequent in the opensource world, as it moves very fast, I guess there's a lot of stuff out there which is plain obsolete. Should I let my software rot as I move forward in my development targets, or take the effort of keeping it (even barely) alive, even if it does not pay off in terms of users, and personal productivity?
CW as it's definitely subjective.
Software like any other entity has a shelf life. If no longer needed then it will (should!) die. Unlike other things it will always (well if media survives) be available forever and as such can be resurrected if needed. It need not stay alive.
I saw this many years ago looking at the source code to some termulator. It was a very well thought out and elegant to look at and interesting for a newbie coder to read. However it was obsolete even then. Felt kind of wrong but it was dead!
Move on and enjoy doing the stuff you want to. Your productivity will be decided by how much you enjoy what you are doing.
How are you measuring productivity? If you fix half a dozen warnings so a codebase compiles comfortably on a new compiler and thereby resurrect an entire app, then your productivity is huge, many times anything you could achieve by writing new code. Of course, it is as dull as anything and feels like a real drag to do this, but maybe you shouldn't be measuring enjoyment and calling it productivity :-)
Of course, if this is open source and there is no money to be made, then whatever you do has zero productivity, unless you count enjoyment as production!
Bottom line: if you aren't being paid, then you can do whatever you feel like.
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 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 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 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 8 years ago.
Improve this question
in the past few weeks I have heard about a phenomenon called 'code-kata'. When I get it right, it means coding an exercise again and again. What is its point? Does it improve your abillity to design better software? If yes, why does it do so?
This was the first time I've heard of this, so after a quick google, here's my gut reaction:
Code Kata is not repeating an exercise over and over again. Rather it's about constantly expanding your "comfort zone" so you can grow as a developer.
Simply working on projects that you know how to do won't help you. You need to try and tackle projects that you would most likely fail at on your first attempt.
The end goal is that if you continuously try, fail, try again, fail again, etc, sooner or later you will succeed. When you do, you've mastered some new knowledge, and become a better developer.
Enough repetition of this will obviously improve your skill.
(Sorry if it's a bit of a brain dump)
I collected a bunch of references here: http://slott-softwarearchitect.blogspot.com/2009/08/code-kata-resources.html
The most important of these is http://codekata.pragprog.com/
It's not primarily to improve your design skills, rather it is a way to improve your productivity in your chosen IDE.
Repeating a familiar task over and over again allows you to watch out for and take advantage of IDE shortcuts and features that you were previously unaware of to shave seconds from your time. It will also help you find any unnecessary steps you take out of habit so you can cut them out of your routine.
We tried a few of these at my company, our thoughts were to develop a simple game (obviously something with a bit of logic we'd not know how to do). We'd all have a go at doing it, then we'd keep improving it as much as we could until we thought we had the best way to do things, then we'd meet up again maybe a week later and compare our results. It's interesting to see how different people come up with different solutions, and everyone learns from the experience. Maybe not a proper kata, but we always try and bend these things to something we'd find useful :)
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
Can I make a difference at an open source project?
I haven't gotten a degree or anything but I am really interested in computer science and I have most of the fundamentals down.
Is there a project I can make a difference at? If not, any sites where I can further my knowledge and review the fundamentals (advanced concepts as well) of computer programming?
Scour around GitHub for projects, there are plenty that could use some help.
At the very least, write tests for untested code and submit them back. Even the littlest of contributions are appreciated.
Newcomers to an active Open Source project often feel like they are walking into a busy kitchen. A lot of different things going on and you feel like you are just in the way.
But often its not the case.
I can't point you to a specific project since i do not know your skillset or what you want to focus on.
Getting into an Open Source project can take time, its mostly based on the size of the project but usually its trying to see what is needed.
What i recommend is the same most people do, find a project that inspires you to make it better (even though its good to begin with), since that will make you want to stick around during the harder times.
Absolutely. Writing documentation and unit tests is good advice, but I'd suggest instead you find something you're particularly interested in, perhaps a piece of open source software you already use, and add a feature that you yourself want to use. It'll be more difficult, but it'll actually keep your interest and get you real world experience. Worst case your patch won't be accepted, but if it's a decent project they'll tell you why and what you need to do to make it acceptable.
Or, pick a small problem you want to see solved, and write an open source solution for it. The key is actually be interested in the problem you're solving.
Open source software is not magically high quality code; in fact it's not unusual to find sloppy code and practices. Don't be intimidated, jump in and give it a try. My first piece of open source still has a few users over 10 years later, but the code quality makes me cringe everytime I look at it.
You can visit Sourceforge.net and look for projects that need help.
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.