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 1 year ago.
Improve this question
Foreword: One could argue this question would be more at home on Law SE, but considering most lawyers aren't even aware of what a hackathon is, this question has a far greater chance of being properly answered here. If you disagree with that judgement, definitely let me know.
Now onto the good stuff
I personally love hackathons. They're a chance to develop some of the most useful skills in programming, like teamwork, rapid debugging, problem simplification, sleep deprivation tolerance, and that ability to turn an idea into a usable product as quickly and efficiently as possible. And yet there's something nagging at me: at some of the bigger hackathons, genuinely great ideas come about, ideas that could seriously be worth something. For example, Techcrunch Disrupt SF produced BlazingDB, a means of running very expensive database queries through GPUs, which is fairly genius considering any query on a distributed database is basically already a map-reduce operation, and that's just one name from the first hackathon I thought to google.
So who owns the products produced at a hackathon? The host? The creators? The sponsors?
This will be subject to the terms of conditions that you agree on when you join a hackathon. I for example will join a 2 day innovation hackathon next week and had to obey to the rules stated in the confirmation of participation policy.
It should usually look like this:
Confirmation of participation
I confirm my participation in the 'NAME OF HACKATHON' event on 'DATE and VENUE'. I understand that all outputs created at the above hackathon event will be on the basis of the 'NAME of LICENCE' as detailed at 'WEBSITE WHERE TO FIND'. By participating in this hackathon event, I hereby give permission to 'HOST NAME' to use any pictures and videos taken during the event that include myself for the purposes of organization promotional material and publications.
Mine used the following license: https://creativecommons.org/licenses/by/4.0/legalcode
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have bought Jira, Greenhopper and Confluence and I have been using their products, but I have not been very good at writing tasks properly.
Let say you have a task in your project that you know consist of several minor tasks, then you would make subtasks to the overall task. What happens when you have completed all the subtasks? Do you drag the overall task over as well (I mean the parent task)?
How do you write your tasks? Do you write them just like: "Create Customer table in database"? And if this task consist of making indexes, constraints etc do you write subtasks to it? Or do you write tasks in another way?
As all things management there is no common practice in this, but here are some guidelines I personally use and we integrate in our company.
The summary should be descriptive of the issue. It should not contain a word describing an issue type: bug, feature, task etc. That's what the "issue type" attribute is for. For example: "Re-check the site for any problems, resolve permissions issue" or "Text corrections".
It is good to have the Priority, Due Date, Environment, Component/s, Affects Vers, Fix Vers and Labels attributes - for those that you're using but keep in mind that the more attributes defined the more information an issue holds, the more descriptive it is and the more manageable.
The description field should hold all available information described in a formal manner.
Sub-tasking:
This solely depends on your organization, but there was a bug in Greenhopper that I personally reported and is now resolved:
"Sub-tasks' estimate does not show in Master Task in RapidBoard's Plan Perspective"
"We are experiencing a problem with rapid board sprints.
Our Master issue * does not have an estimation of its own, but does have an estimation when you include the subtasks.
As you can see from the attached screenshots, when we include this master issue in the next sprint, we do not see the estimation sum for all of its child issues.
They are not shown at all."
So for subtasking we now use this new (fixed) feature - the master tasks's estimate is the sum of all estimates for an issue. I personally subtask only when the master is something very complex, but with my job that's every day's work.
Hope this helps but again this is my personal opinion.
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 5 years ago.
Improve this question
I have chosen to use the development method RUP (Rational Unified Process) in my project. This is a method I've never used before. I've also included some elements from Scrum in the development process. The question is what the requirement specifications should contain in a RUP-model? Is it functional and non-functional requirements? And what should be included in a technical analysis and security requirements for RUP? Can’t find any information. Notes about this would be helpful.
Hope people with RUP experience can share some useful experiences
RUP has 3 main parts:
Roles
Activities
Work Products
Each ROLE do an ACTIVITY and as a result a produce a WORK PRODUCTS...
For example Analyst [Role] Develop Vision [Activity] as a result we will have Vision [Work Product]...
Besides this RUP gives us some GUIDELINES and CHECKLIST to do right our ACTIVITY and WORK PRODUCTS...
RUP gives us templates for WORK PRODUCTS but they are just to give an idea what they may be look like...
Suppose for vision you can use RUP template but you can just use a post-it notes and just write an "elavator statement" like this:
For [target customer] Who [statement of the need or opportunity] The
(product name) is a [product category] That [statement of key
benefit; that is, the compelling reason to buy] Unlike [primary
competitive alternative] Our product [statement of primary
differentiation]
Even Work products can be simple statements that you write on your WIKI...They can be in any form...
They must not be "static written" docs... They can even be "video" .
Suppose instead of writing Softaware Architecture docs [Architecture Notebook in OpenUP] you can just create a video in which your team explain main architecture on white board....
****WARNING FOR RUP WORKPRODUCTS TEMPLATES:**
DO NOT BECAME A TEMPLATE ZOMBIE.YOU SHOULD NOT FILL EVER PARTS OF IT...
YOU SHOULD ASK YOURSELF, WHAT KIND OF BENEFIT WILL I GET BY WRITING THIS...IF YOU HAVE NO VALID ANSWER, DO NOT WRITE...
DOCUMENTATION SHOULD HAVE REAL REASONS, DO NOT MAKE DOCUMENTATION JUST FOR "DOCUMENTATION"...**
RUP has rich set of WORK PRODUCTS...So chose minumum of them which you will get most benefit...
For a typical projects generally you will have those Requirements Work Products:
Vision : What we do and Why we do? Agrement of StakeHolders...
Suplemantary Specification [ System-Wide Requirements in OpenUP] :
Generally capture non-functional [ which the term i do not like] or
"quality" [ which i like"] requirements of system.
Use-Case Model : Capture function requirements as Use-Cases
Glossary : To make concepts clear...
RUP is commercial but OpenUP is not...So you can look OpenUP WORK PRODUCTS templates just to get an idea what kind of info is recorded in them...
Download it from and
Eclipse Process Framework Project http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.php and start reading from index page:
...-->
...--->
--->
----->
--->
....>.........................................
---->.......................................
Lastly you can find usage of those WORK PRODUCTS in an agile manner at Larman book Applying UML and Patterns...
And again : DO NOT BECAME A TEMPLATE ZOMBIE!!!
Try the Rational Unified Process page at Wikipedia for an overview.
The core requirements should be documented in the project description. RUP tends to place a lot of emphasis on "use cases", however it is very important not to lose sight of the original requirements at all levels of detail, because these will answer the "Why?" questions. If the developers only see the uses cases, they will know What they are supposed to build (effectively the functional requirements) but not Why it is required. Unless the developers have easy access to the original analysts, this can cause very serious problems.
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
Ok, so you've got an idea for a potentially successful online start-up. You know that you'll never set the thing up yourself, you prefer the stability of your permanent job. Then you think, "Hey maybe my boss would be interested in backing this as an internal project. Obviously I'd want X% of the profits for coming up with the concept in the first place and I want to be able to retire when we get bought by BigCorp."
Can you follow any legal procedures to prevent anybody you tell about a business idea from exploiting it independently?
What kind of deal should you be looking at (e.g. profit share, shares etc)?
IANAL, but I've been around the block a few times.
First, find a competent attorney that specializes in startups and get some professional advice and follow it. Preventive lawyering is really a whole lot cheaper than waiting until it is too late.
Second, protect yourself and make sure you do everything in writing. If your employer doesn't bite and you decide to do it yourself then you'll be protected when you're successful and your company comes back later and tries to claim ownership over the idea. I've seen this happen more than once.
Third, try to get the people you pitch to to sign a non-disclosure. If they have half a brain they won't sign one, but it's an important sign of your intent. Without an NDA do your best to not pitch your idea to anyone who can take the idea and run with it based on your elevator pitch. That generally means really competent technical people, or an expert in the business area.
If you get to the point of having to worry about a deal go back to that competent attorney you retained.
To answer your first question: no. There's nothing you can do that will stop someone from exploiting an idea you have. Apart from patenting it. (Which you aren't really supoposed to be able to do unless you've already at least partly implemented it in the first place).
My advice would be: if you know someone you trust not to steal your idea, tell them. If not, don't.
Also, if you have an idea and you tell your boss, you're not really entitled to anything in terms of ownership of X% of profits. That's just supposed to be part of your job.
Sorry: this probably seems like a negative answer, but I'm trying to be realistic.
Ben
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
I work as a PHP developer, and my boss is driving me crazy. He calls me every now and then, gives me tasks even when the previous tasks haven't been completed. Forbids me from meeting with clients and tells me incomplete specification verbally or over the phone, and expects to have working applications from the first deployment. Can any body suggest a way to curb this guys enthusiasm?
document what you are spending your time doing.
document requirements as they come in (through whatever channel)
provide both of these to your boss as frequently as necessary in order facilitate conversation about missing requirements or prioritization of your time
Start looking for another job and give him a pre-notice. This will curb his enthusiasm. Some people are to be avoided at all costs.
//Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein
Talk to him about the communication problems. It's usually a two-way problem. If he's giving you incomplete specs, why aren't you asking for more complete ones?
If you just want to stick it to him, then find a better job. If you're committed to making it work, then put some serious thought into the root of the problems you're having, and get him on board with helping you solve them.
I'd suggest having some sort of task list somewhere so that when your boss adds something to this list, he can see what you are doing and have estimates for how long some things will take.
As for the requirements being incomplete, this is why some like Agile approaches where you would get your boss in to test something regularly to verify that it is acceptable before putting something into production.
As others have mentioned who can type faster than me, one thing you can do is to try setting up some type of project management/bug tracking system for him to use. I've used FogBugz with success which requires no installation and has a free plan for small teams. You can setup an email account that he can send requests to.
When proposing this to your boss, do it in a way that will show that your goal is to help keep track of your tasks and priorities. But also be prepared for additional work. If he is agreeable to it he may want to see frequent status reports and where you are spending all of your time.
If you can get more complete specifications this can help drastically. It'll help you understand the project better. It'll help you estimate time for completion. And my favorite -- it'll help prevent double-work. There's nothing worse than getting incomplete requirements, building something wrong, and then finding out that you need to redo it.
If you can I'd try to find a good way to suggest this to your boss without stepping on any toes. If he understands the benefits he may be more open to the idea of being more thorough with you. What it'll really do is make you more efficient at your job.
Oh, and you may want to take a look at my answer to this question relating to time estimation:
How am I supposed to know how many days something will take?
The other suggestions of keeping things in writing at least for yourself are valid. However, for the kind of boss you describe with which I have some familiarity, it may not work.
Some bosses just never learn or already know what they are doing is wrong and do it anyway because to them, saying "yes" to the client and getting a signoff on a bigger contract today is more important than programming methodology that could delay a payment for 3 weeks (testing? why do we need to test? you tested it, right? two weeks for function X?! all you have to do is add a button, right?).
To many bosses, programming is just one of the tools needed to run their business. To them, it's a business to make money and programming methodology/quality is secondary.
What you do to keep yourself sane and safe if you want to stay with this boss is at least keep written records of every request and when problems come up, remind him why they happened. If possible, ask that all specs be delivered at least by email instead of verbally.
You always have the choice of going somewhere else if things don't improve.
Good luck.
I have struggled with this same problem at a few jobs.
I've observed that there is a type of programmer who can survive in this environment: one who simply works on whatever the boss says is the priority of the moment, and doesn't worry about deadlines at all. Just keep putting things on the back burner, and resume working on them the next time the boss asks for it. Endure the occasional tirade from your boss when something he asked you to start 12 months ago isn't done yet, because you've been working on whatever he gives you.
If you aren't comfortable with that sort of existence (and I would not be), then the best strategy I can suggest is that you have an open conversation with your boss about it:
It's important to me to do a good job,
but I feel like the work requests are
coming in faster than I can complete
them. I know that priorities
inevitably shift, so I'd like some
help from you to understand when this
happens, and how to balance my time
among the tasks to best meet your
needs. Can we talk about how to stay
in sync about priorities?
If the tasks can't be prioritized,
then I need you to understand that I
can't be productive on so many tasks
at once. It's just not humanly
possible. Have you considered hiring
additional programmers so we can
balance the workload and get it all done
in a timely way?
If he tries to stall or contradict or tells you to "work smarter, not harder" then you can escalate:
Let me put it another way: if you continue to give me tasks at the rate you have been, but don't prioritize them clearly, then you are going to hire another programmer. Whether this hire is your second programmer, or else my replacement, is up to you.
Basically, communication is good. Start by being diplomatic and phrasing everything in terms of how you contribute to his success. But increase the degree of bluntness until it sinks in.
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
Here's a scenario I'm sure you're all familiar with.
You have a fairly "hands off" customer, who really doesn't want to get too involved in the decision making despite your best efforts.
An experienced development team spend hours discussing the pros and cons of a particular approach to a problem and come up with an elegant solution which avoids the pitfalls of the more obvious approaches.
The customer casually mentions after a quick glance that they want it changed. They have no understanding of all the usability / consistency issues you were trying to avoid in your very carefully thought out approach.
Despite explanations, customer isn't interested, they just want it changed.
You sigh and do what they ask, knowing full well what will happen next...
3 weeks later, customer says it isn't working well this way, could you change it? You suggest again your original solution, and they seize on it with enthusiasm. They invariably seem to have had a form of selective amnesia and blocked out their role in messing this up in the first place.
I'm sure many of you have gone through this. The thing which gets me is always when we know the time and effort that reasonably bright and able people have put in to really understanding the problem and trying to come up with a good solution. The frustration comes in contrasting this with the knowledge that the customer's choice is made in 3 minutes in a casual glance (or worse, by their managers who often don't even know what the project is really about). The icing on the cake is that it's usually made very late in the day.
I know that the agile methodologies are designed to solve exactly this kind of problem, but it requires a level of customer buy in that certain types of customers (people spending other peoples money usually) are just not willing to give.
Anyone any clever insight into how you deal with this?
EDIT: Oops - by the way, I'm not talking about any current or recent customer in this. It's purely hypothetical...
Make your customer pay by the effort you are putting into designing and developing the solution to their problem.
The more you work, the more you get. The customer will have to pay for his mistakes.
Customer will eventually learn to appreciate your experience and insight in the programming field.
Niyaz is correct, unfortunately getting a customer buy-in is difficult until they have been burned like this once before.
Additionally describe to the customer the scenario above and state how much extra it would cost if you went three or four weeks down the line and had to rewrite it due to a change and then let them use the prototype. It may take a few days to put one together so they can see both options (theirs [the wrong way], and yours [the right way]). Remember they are paying you not only for your ability to program but also your experience and knowledge of the issues which crop up.
Whatever the decision the customer makes, ensure that you get it documented, update your risks register for the project with the risks that the chosen implementation will incurr and speak to the project manager (if its not you) about the mitigation plans for them.
I agree with Niyaz. However at the time the customer suggests the change you should work out what the impact of the change will be, and how likely that impact is to happen. Then ask whomever is responsible (it's not always that customer) for the deliverable if they approve the change.
Making the impact clear (more cost, lower reliability, longer delivery time etc) is very important to helping the customer to make a decision. It's very important to describe the impacts on the project or their business in a factual way, and assess how likely that impact is to occur. "Maybes" and "i feel" are very ignorable.
After that as long as the right people approve the change and as long as they pay for it.. well you did give them what they wanted :)
One thing we have done with some success in the past in these kinds of situations is to hand the issues over to the client.
"OK, you want to change it - this is
what will happen if you do that. These
are the issues involved. You have a
think about how you'd like it to work
and then get back to us".
This approach doesn't tend to yield good solutions (unsurprisingly) but does tend to let the client see that it's not a "gut feeling", wild stab in the dark kind of question.
And failing that, it usually makes them stop asking you to change it!
Usually a scenario like this is caused by 2 things. The ones that are supposed to give you the requirement specifications are either don't put their hearts into the project because they have no interest in it, or because they really have no idea what they want.
Agile programming is one of the best ways, but there are other ways to do this. Personally I usually use a classic waterfall method, so spiral and agile methods are out of the questions. But this doesn't mean that you can't use prototypes.
As a matter of fact, using a prototype would probably be the most helpful tool to use. Think about the iceberg effect. The secret is that People Who Aren't Programmers Do Not Understand This. http://img134.imageshack.us/my.php?image=icebergbelowwater.jpg
"You know how an iceberg is 90% underwater? Well, most software is like that too -- there's a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers...." - Joel Spolsky
Generating the prototype takes time and effort but it is the most effective way to gather requirements. What my project team did was, the UI designer was the one that made the prototypes. If you give the users a prototype (at least a working interface of what the application is going to look and feel like) then you will get lots of criticism which can lead to desires and requirements. It can look like comments on YouTube but it's a start.
Second issue:
The customer casually mentions after a quick glance that they want it changed. They have no understanding of all the usability / consistency issues you were trying to avoid in your very carefully thought out approach.
Generate another prototype. The key here are results that the users would like to see instead of advice that they have to listen to.
But if all else fails you can always list the pros and cons of why you implemented the solution, whether or not the particular solution they like is not the one you insisted on. Make that part of the documentation as readable as possible. For example:
Problem:
The park is where all the good looking women jog to stay in shape. Johnny Bravo loves enjoying "mother nature's beauty", so he's lookin to blend in... you know... lookin all buff and do a little jogging while chasing tail.
Alternative Solutions:
1) Put on black suede shoes to look as stylish as you can.
2) Put on a pair of Nike's. Essential shoes for running. Try the latest styles.
Implemented Solution:
Black suede shoes were top choice because... well because hot mommies dig black suede shoes.
Or else, if they won't pay for the effort, just avoid putting that much resources into the solution of the problem, and just give them exactly what they've asked for and then think about it after the three weeks have passed.
Somewhat frustrating, yes, but that's the way it'll always be with that kind of customers. At least you won't be losing money.