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
Related
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 9 years ago.
Improve this question
I'm starting a massive project for the first time. I was supposed to be one of the developers on this big project, and all of a sudden, the lead developer and his team backed out of the contract. Now I'm left managing this big project myself with a few junior developers under me and I'm trying to get a firm grasp on how this code should be broken up.
Logically, to me, the code should be broken up by the screens it has. I know that might not be how it SHOULD be done. so tell me, how SHOULD it be done? The app has about 6 screens total. It connects to a server, which maintains data about all other instances of the app on other phones. You could think of it as semi-social. it will also use the camera feature in certain parts, and it will definitely use geolocation. probably geofencing. It will obviously need an API to connect to the server. most likely more APIs than just the 1. I cant say much more about it without breaking an NDA.
So again, my question pertains to how the code should be broken up to make it as efficient as possible. Personally, i'll be doing little coding on the project. probably mostly code reviews, unit testing and planning. Should it have 1 file per screen, and parts that are repeated should have their own classes? should it be MVC? We're talking a 30k line app here, at its best and most efficient. is there a better way to break the code apart than the ways I've listed?
I guess my real question is, does anybody have good suggestions for books that would address my current issue? code clean was suggested, that's a good start. I've already read the mythical man month and code complete but they don't really address my current issue. i need suggestions for books that will help me learn how to structure and plan the creation of large code bases
As I'm sure you know this is a pretty vague question you could write a book answering it. In fact, I would recommend you read one, like Clean Code. But I'll take a stab at a 10,000 foot level overview.
First if you are doing an iPhone app, you will want to use MVC because that is how Apple has setup their frame work. That means each screen will have (at least) a view-controller, possibly a custom view or NIB.
In addition you will want your view controllers pointing to your model (your business objects) and not the other way around. These objects should implement the use cases without any user interface logic. That is what your view-controller and view will be doing.
How do you break apart your use cases? Well, that's highly specific to your program and I won't be able to tell you with a (lot of) details. There isn't a single right answer. But in general you want to isolate each object from other objects as much as possible. If ever object reference ever other object, then you don't really have an OO design, you have a mess. Especially when you are talking about unit tests and TDD. If when you test one part you end up pulling in the whole system, then you are not testing just one small unit, are you?
Really though, get a good book about OO design. It's a large subject that nobody will be able to explain in a SO answer. I think Clean Code is a good start, maybe other people will have other suggestions?
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 4 years ago.
Improve this question
G'day,
While having a think about this question here about overdesigning for possible future changes it got me thinking.
What reasons against can you provide to people who insist on blowing out designs because "they might want to use it somewhere else at some stage in the future"?
Similarly, what do you do when people take the requirements and then come back with a bloated design with lots of extra "bells and whistles" that you didn't ask for?
I can understand extending a design when you know it makes sense for requirements or possible uses that exist either right now or in the near future. And I'm not advocating just blithely accepting a list of requirements and implementing that explicitly without providing any feedback on what you think may be missing.
I am talking about what to do when people insist on adding, or having, extraneous functionality so that "we might use it somewhere else at some stage in the future?"
Plenty of good reasons on Wikipedia.
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
The time spent is taken from adding, testing or improving necessary
functionality.
The new features must be debugged, documented, and supported.
Any new feature imposes constraints on what can be done in the future, so
an unnecessary feature now may prevent
implementing a necessary feature
later.
Until the feature is actually needed, it is difficult to fully
define what it should do and to test
it. If the new feature is not properly
defined and tested, it may not work
right, even if it eventually is
needed.
It leads to code bloat; the software becomes larger and more
complicated.
Unless there are specifications and some kind of revision control, the
feature may not be known to
programmers who could make use of it.
Adding the new feature may suggest other new features. If these new
features are implemented as well, this
may result in a snowball effect
towards creeping featurism.
See also: http://en.wikipedia.org/wiki/KISS_principle
Especially on an embedded device, size is money (larger Flash part, say, which costs more and has a longer programming time at manufacture; or more peripheral components).
Even on a Windows application, the larger your application and the more features it has, the more it costs to develop; wait until you know what's needed and what's not and you'll waste far less money developing stuff that turns out not to be what was needed at all.
Also, any additional functionality brings with it the potential for bugs.
It's good to think properly about the requirements before developing something, but over-designing is often just borrowing trouble.
Them: "We might use it somewhere else at some stage in the future."
Me: "Yes, we might. And we might not. And we can't know, now, in what ways we might want to. And if we do want it at some stage in the future - that's the time when we'll know the ways in which we want it. That's when we can write it with confidence. On the other hand, if we write it today, but never need it, we've wasted resources to develop something we didn't need. And we've added to our code bloat, so it's harder to find the pieces of our code base that are in use, because we've got all this (presently) unnecessary code crowding out the useful stuff."
In our team we just say "YAGNI". It reminds people why. There is MORE than enough stuff on the web about YAGNI if you think you need to collate it to provide a report.
Actually, having someone say "YAGNI" to you on our team cuts a little because it's like saying "C'mon; you know better than that", which always hurts a little. :)
It's a balance, as a rule I over design only where it's cheap to do so. For instance, I wouldn't write a function that takes in 2 parameters and adds them, instead I'd write a function that takes n-parameters and adds them. However, I don't write a function that takes n-parameters and adds them using assembly.
You say
I can understand extending a design when you know it makes sense for requirements or possible uses that exist either right now or in the near future.
and I guess that sometimes people see this line as blurry something that "makes sense" to you may be over-design to someone else.
Overdesign (solving a problem in a way that is more generic than needed) a specific piece of architecture is acceptable only if you can afford it.
If you accept extraneous functionality (which is generally speaking different from overdesign) you need - again - to accept the costs that come with it (time ==> money) - if you can't afford those extra costs then you got your answer :)
There's a big difference in providing for future functionality and adding future functionality. A good design should have the "hooks" or whatever to provide for new features or modifications.
There are two ways that you can possibly handle this situation. The first way is that if they are contractors and providing the software to you. You can simply refuse to pay for all of the extra functionality and impose very strict deadlines for your required functionality. If they miss the deadline then you impose financial penalties for every day they are late.
The other way is if they actually work for you. If this is the case then you can get rid of them or downgrade them in their performance reviews.
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 9 years ago.
Improve this question
At a place I used to work they typical response to any problem was to blame the hardware or the users for not using the system perfectly. I had adopted the philosophy that it's my fault until I can prove otherwise prior to that job (and so far, at least 99 times out of 100 it's correct).
One of the last "unsolvable" problems when I was there was an abundance of database timeouts. After months of research, I still only had theories but couldn't prove any of them. One of my developers adamantly suggested replacing the network (every router, switch, access point) but couldn't provide any evidence that the network was the cause; it was, however, "obviously the cause" according to my manager (no development/IT experience) so he took over the problem. One caveat and Fog Creek plug: He couldn't account for the fact that the error reporting via FogBugz worked perfectly and to the same SQL Server as the rest of the data.
A couple, timeout-free months later, my manager boasted that he had fixed the timeouts ("Look, no timeouts!"). I had to hold back from grabbing a rock and saying "Look, no tigers!" but I did ask how he knew they would have occurred to which I got no response. The timeouts did return (and in greater numbers) a couple months later.
I'm pretty content with how I handled the situation but I'm curious how the SO crowd would have responded to letting a superior/colleague implement a solution you know (or are very sure) is wrong and will likely waste thousands of dollars?
Let them, but at the same time continue searching for the real cause.
A couple thousand dollars is money well spent if it keeps me from going against that kind of thinking (which is futile).
Well, if the problem is upper management, then I would do as you have done - lodge your complaint, then follow instructions. If it turns out they were right (it happens every now and then) then you look like a good employee despite your misgivings. If it turns out you were right, then they might be more willing to listen to you given that you allowed them their turn.
This is, of course, optimistic.
In the case of a colleague, take the problem up a level and consult your superiors for advice on how to approach the subject. Be fair to both your perspective and that of your colleague's, then follow the advice you're given.
Sometimes it's best to leave a manager be. If you think about his pressures and responsibilities he had to be seen to be doing something, rather than "nothing". After enough time "investigating" resolves into nothing to outside parties that need the timeouts to stop.
By taking an action he creates an opportunity to keep researching. The trick is to find a way to put your solutions in his context. Here is something we can do now, and here's what we can continue to do. For example, "We can replace the networking gear as a precautionary step, and then look at the version control logs to rule out that possibility."
This gives him something proactive so he can look productive up his chain while achieving the solution you want which will ultimately be successful.
In the long term you should look to work for someone who trusts your technical decisions implicitly, you can talk candidly with and who well help you help him navigate the politics in a way you both know what's going on. If you manager isn't that person, move.
Is this a big problem? Its not your job to save your company dollars other than that you would like your company to remain solvent so you get paid.
If its just one manager, he will be weeded out sooner or later, if your entire company culture is like this, maybe it would be time to move on.
In the mean time, see if you can see this from your manager's perspective.
I'd consider you're manager's intent to be a good thing. It's the people that don't want to bother that I find more difficult. It's just best to find a way to use that energy to be helpful.
One common problem for lots of people (occasionally myself), is that they flail around when trying to diagnose a problem. If you're wildly guessing at it, then particularity with modern computers, you have only the slimmest possibility of being right. Approaching this type of problem with that type of attitude, generally means that you'll never fix it.
The best way of handing complex debugging, is by divide and conquer. In this case, first think up a test, them implement it. Did that test act as expected? Depending on where you are with your tests, you are getting closer or farther away from the problem. The key, is that ALL of the tests must result in some concrete (objective) behavior. If the results are ambiguous, then the test is useless.
If you're getting a disconnect in part of the system, but some other part is not, then you have a huge amount of valuable information (it also shows it's not the network). What's the difference between the parts? Just start descending until you get somewhere ...
Getting back to your manager. Whenever I encounter that type of personality problem, I try to redirect the energy into something more useful. The desire is there, it just needs some help in getting shaped. If you can convince your manager to make sure the tests are concrete, then if they do enough of them, they'll produce enough information to correctly guess the bug. Sure, a more consistent approach might be faster, but why turn down some free assistance. I generally feel that there is some useful role for anyone on any project, it's all about making it possible to harness their efforts ....
Paul.
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.