Related
Sometimes, when I present a part of the software development process to certain people, say the supervisor or the manager that they don't have experience say
Automated unit tests and integration tests vs. their manual functional testing.
Using code generators, and scripts for repetitive tasks.
I sometimes met with resistance. Some of the reasons are the following:
They say that that's the way we do things here. Our system works and there is no need to add in our process.
They are busy being busy. They say is their job is to get us projects and our job is to deliver it to them to their satisfaction. They are satisfied when if it is a manual system, repetitive but on time.
They are very conservative about code generators. I gave them an estimate that it takes a significant time overhead for the first project to use this and time to train my teammates since this approach is relatively new to them. The overhead for the first project to them overshadows the benefit in the long run, but I explained the convenience it is to us developers, but they are always stuck to do things the old way.
What would be your strategy for this?
Wait for a problem to show up and then make your move.
You have to be a salesman, at the end of the day. You have to tell people why your proposals will make their lives easier.
If you can back up your claims with some sort of time spent/time saved data, you're onto a winner. Another thing is to get yourself a reputation gradually, by agreeing changes be implemented in phases. Implement a simple change on a small piece of the project and prove that it made a difference to them. Then roll it out a bit more, and move onto the next thing like unit testing or code generation. Given time it'll work itself out.
I don't believe you can't force people to read books, they'll shelve 'em and think you're being obnoxious. Best thing is to get small results, and use those as stepping stones to be allowed to aim for higher goals as people realise that maybe there are better ways of doing things after all.
If you're really passionate about it, you can always invest a little of your own time, and prepare a short demo (30 mins tops) that shows them how quickly you can create a tiny app without code gen, then the same app with a couple of bits code-genned. The proof of the pudding is in the eating.
I think that only way to convince someone about something is to reveal benefits what it provides.
It's easier to ask for forgiveness than it is to get permission.
There's no objective return-on-investment style measurements for "improving" a software development process. Software development is inherently hard -- it's knowledge capture -- there must be unknowns. If everything was known, you'd already have the software in hand.
Consequently, you can't ever convince a manager of anything up front.
You can only demonstrate that you are able to done something better, cheaper or faster. When they ask what the secret to your productivity is, you can show them your tools, method or approach.
Until they ask, you don't really have enough evidence to change anyone's mind. When they finally ask, then you don't need to change their mind, you need to show them your solution.
Since they don't want to derail their "do everything by hand" schedule to invest in your tools, you have to build your tools in steps, one project at a time.
"You can get a lot farther with a smile and a gun than you can with just a smile."
- Al Capone
Just kidding, but its the first thing that cross my mind :)
The gun is a metaphor (duh), like for a bug that someone spent days figuring out that with a good process he good spend in a more fun ways.
I'm in the process of going back over some of the more minor TODO's in my code. One of them is in a class that handles partial dates, e.g. Jan 2001. It works fine for dates that will be seen in our system (1990 - 2099) and gracefully fails for other dates.
The TODO that I've left for myself is that I don't handle dates in the century 2100 and beyond. I don't really think it worth the effort fixing this particular problem, but I am cognisant of the Y2k bugs. If we were in 2080 already I think I'd be thinking differently and would fix the bug.
So how long does code last for? How far ahead should we plan for our systems to keep running for?
Update
Ok, thanks for all your input. I think I'm going for the option of leave the TODO in the code and do nothing. The thoughts I found most interesting were:
#Adrian - Eternity, I think that's the most correct assumption, your point about VM's is a good one.
#jan-hancic - It depends, yes it does.
#chris-ballance - I'm guessing I'll be dead by the time this restriction is hit, so they can come defile my grave if they want, but I'll be dead, so I'll just haunt his ass.
The reason I decided to do nothing was simple. It added negligable business value, the other things that needed looking at did add value so I'll do them first and if I get the time I'll fix it, but really it'll be nothing more than an academic exercise.
Longer than you expect.
Eternity.
Given the trend that old system keep running in virtual machines, we must assume that all useful code will run forever. There are many system that run since the 60ies, eg backend code in financial sector, and there seems to be no indication that these systems will ever get replaced. (And in the meantime, the frontend is being replaced every other year with the latest fad in web technology. So, the closer your code is to the core of your system, the more likely it will run forever.)
You can't have a general answer here. Depends on what kind of project you are building.
If you are writing software for a space probe then you might want to code it so that it will work for the next 100 years and more.
But if you are programming a special Xmas offer for your company's web page, a few weeks should be enough ...
Assume that whoever will maintain the code is a psychopath and has your home address.
Nobody really knows. Professional programming has been around for 30-40 years, so nobody really knows if code is going to last for 100 years. But if the Y2K bug is an indication, it is that a lot of code is going to stick around for a lot longer than the programmer intended. Keep in mind that even if you take that into account, it could still stick around longer than you expected. No matter how much you prepare, it might still outlive it's intended life expectancy.
My advice is to not plan for code to last 100 years. Instead try to make sure all your code will work for the same length of time, that is, part of it should not fail in 2 years, while the other part should fail in 100 years. Remember, you should always fix the weakest link first, so there is no point making the strongest link stronger.
Sometimes, code lasts longer than you think. But, more important is the slippery slope argument. Once you forgive yourself a bit of non-bullet-proofness, you may be tempted to optimize further and skimp on logical correctness, until it finally bites you.
By the way, I recommend to have an issue ID (such as FogBugz case number) in every TODO comment, so that people can actually subscribe to and track this TODO.
in Dan Bernstein's immortal words: Don't contribute to the Y10K problem!
I don´t think the code will last so long.
Think about all the inventions and progress made in the last 90 years.
In 2100 we won´t have to write down code.
There will be some kind of brain-machine interface.
Well, we recently made a timestamp format where time is stored in a unsigned 64-bit integer as microseconds from 1970. It will last until the year 586912, which should be enough.
Coding for "forever" is unnecessary - of course you could use BigIntegers and such everywhere, but why? Just be prepared for more than 5 or 10 years. Twenty year old production code is not quite unusual nowadays, and I suspect that the average life cycle will get even longer in the near future.
It depends on how much business value the code has and how much resources it takes to write it from scratch. The more value and resources the longer it lasts. Ten years and more is typical for commercial "works, don't touch it" code.
I always tried to code like my applications must work "forever". I am very sure I wont be around anymore in 2100 but knowing my software has a build in expiration date doesn't make me feel good. If you know about such things try to avoid them! You will never know but some unknown programmer in the future may be grateful.
Right up until the time that it breaks, or otherwise ceases to be useful, and then for a bit longer after that
The essential things are:
How good is your internal date class (get a very robust library version and stick to it!)
It's not just the passage of time, but also the growth in the range of inputs your users want. For example, maybe you have 30 year mortgage inputs now, but next month someone decides to input a 99 year lease with maturity 2110, or a 100 year Disney bond!
If you accept 2 digit year inputs with a date window, think very carefully about how that is applied to start and end dates, and give lots of immediate feedback.
Here are my two cents:
When we design a project, we usually declare it to last "at least" 5 years. Usually no more than 10 years before we re-design it and build it all over. (We're talking about mid-large size projects here).
What usually happens is that the new project you build is supposed to replace the old one, either techonology wise (i.e. moving from MF to windows, VB to .net etc.), but this project never ends. So your client ends up working with 2 systems at once and that leftover system is what later is referred to as "legacy".
If you wait long enough, a third project will rise causing the client to work with 3 systems at once and so on...
But to answer your question, I would bet on 5-10 years before redesign, and unless your dates are supposed to be long into the future - no need to worry about the 2100 limitation.
IMHO it comes down to craftmanship : the pride we take in our work, coding to a standard we would not be ashamed another real coder to see.
In the case of dates like this, you've stated that it gracefully fails after 2100. This sounds like you can remove the TODO without a bad conscience, because you have built in a response that will allow the cause of failure to be easily diagnosed and fixed in the (however likely or unlikely) circumstance that a failure occurs.
There are examples of code running on older machines which is 40 or 50 years old.
(Interesting bits in this thread: http://developers.slashdot.org/developers/08/05/11/1759213.shtml).
You've got to ask yourself about the nature of the problem you're solving but generally speaking even "quick fixes" will be around for years so you could realistically be looking at a decade or more for code intended to have a decent shelf life.
The other things you need to think about is:
1) What is the "active life" of the application - that is where it's going to be used and processing.
2) What is the "inactive life" of the application - that is it's not going to be used day to day but might be used for retrieving and viewing old records. For instance UK audit law means that records need to be available for 7 years, so that's potentially 7 years from last system use.
3) What is the range of future data it needs to handle? For instance say you're taking down credit card expiry dates - you can have a card which won't expire for a decade. Can you handle that date?
The answers to these questions will generally lead you to the assumption that you should never knowingly write code which has date constraints beyond those the OS/Language you're using dictates.
The question isn't "How long does code last?" but rather "How long will things in my code affect an application?"
Even if your code is replaced, it's possible that it will get replaced with code that does the exact same thing. To some extent, this is the direct cause of the Y2K problem. More to the point, it is the direct cause of the Y2038 problem.
Also keep in mind what you mean by last.
For example, the original UNIX operating was developed 30 years ago. But during that 30 years, the product has evolved over time.
Though, it wouldn't surprise me if a little but of original code still exists in it today.
So think of it 2 ways ... 1) do you ever antisipate the code being touched in the future, 2) the product/code will evolve if you have support and involvmment.
My current shop has a large code base that runs financial applications with complex business rules. Some of these rules are encoded in stored procedures, some in triggers, and some in 3gl and 4gl application code. There is running code from the late 90's, and none of it in your "traditional" Legacy languages like COBOL or FORTRAN. As one could imagine, it's a steaming pile of spaghetti code, most created before TDD meant anything, so people are reluctant to touch anything.
I have had occasion to be brought in on contract more than a decade after the fact to consult on porting code to a new platform (OS/2 just isn't that popular these days!). When in doubt, assume that your code will live longer than you will. At the very least, document the heck out of limitations like this; fix them unless that takes tremendously more work than to document them.
In 1995 I started work at a new job, on an 8 year old code base.
So it's incept date was 1987 or thereabouts.
The code is probably still in service. Thats what ? 23 years.
There's been some moves of the company, but they probably kept the software ( because it works)
If it's still in service now, it will still be in service in a decade or so.
It's not surprising, particularly high tech code, in C (mostly)
In 1999 I started at a new job, the the codebase had antecedents back to 1984.
The new version I designed in the 2000's is still in service, with design elements like data file formats from the previous one ( and so on back) and that would be a development program over 26 years.
So the year 2086 problem is starting to loom a little as those 32 bit signed time_t's roll over.
Remember that one of the major bonuses of modern programming is reuse.
So that means the code you write originally to solve one problem may get re-purposed and used in a completely different scenario years later (maybe even without your knowledge, by a team mate).
As a side note:
One of the major pluses of automated unit testing, is testing code that you can't even remember is there in a system! :)
As long as people can continue to bill for support with people willing to pay for it.
3-5 years max. After that you have moved on to another job and left your crappy code behind.
Here's what I'm wondering. Every night that our 3 months old baby lets us sleep, I jump to my computer and start coding my hobby projects. I have about 20 different projects that I'm working on: different types of projects, from C++ games to web apps along with some contribution to open source projects. It's truly a passion and has been for a lot of years.
Yet, when I look back, I see that I haven't been able to fully complete one of my hobby projects. I've always done the prototypes and setup the most important features, but with time instead of finishing my project I end up switching to another project that seems "so much cooler" at the moment. Hence I usually end up with buggy and incomplete games that have no end nor story, 3D engines that have the fastest PolygonDraw routine ever, yet lack to implement anything else, etc... The list is long. I think I must have written unfinished Pong over a hundred times different!
I've been told that the remedy is to write specs for my hobby projects.
On one hand, I write a lot of specs at work. I know how crucial they are for defining a product's roadmap and staying within schedule. On the other hand, specs and hobby project just quite don't seem to go along! It seems to me that the learning curve to building a game is actually what makes it fun; not the game itself. Hence the fun of losing time restructuring an entire engine, the fun of creating the most useless features, and so on...
So here comes the question: Do you ever write specifications for your hobby projects? How are they different then the ones from work? How do you manage to complete your hobby projects?
I'd be glad to know while I work on my new project: a piano sonata generator :)
I don't think writing specs is the solution to your problem. Clearly, your "hobby projects" are things that you find fun. You write the fun parts but then avoid the not fun parts that would be necessary to complete something.
If you're just "programming for fun" then good, you're succeeding. I don't think writing specs is fun.
If you really want to "finish" something, the best way isn't to write a spec, it's to not jump to another project when the fun factor dips.
It is all about 'Self project management' ... even for fun.
I feel for you ... I used to have many repos that tended to all get stuck at around revision 200 or so.
Here is what used to happen, because I didn't do enough planning, after around 200 commits, things get messy and need a rewrite ... then interest disappears because it seems like too much hassle.
I learned to write my own specs for personal use
to
Give me focus to get the job done, and not go off into feature creep lane
Remind me what I am working towards
To have great ideas before I get coding
Keep thing more fun for a longer time
For me, writing my own specs is vital to getting anything done!
You wouldn't start a business without a plan would you?
For personal projects I have tons of moleskine books filled with rough specs and ideas. When they mature, they migrate from the note books into real documents and the coding begins.
BIG EDIT: On a drive for personal efficiency and, to get projects finished. I read "Getting Things Done" ... Despite all the hippy crap about 'psyche' and various levels of mind (which im sure is not based in any science) the tips are very good.
I don't get too complicated, but listing out all of the features and requirements that you want included in your application really does help. As with most hobby projects you often don't just sit down and code them straight through for 2 months and finish them. It's an hour here, two hours there, etc. Basically it's very common to forget what you were working on last and what the original purpose of this super great idea for an application was.
If you spend a few hours writing down specs and requirements it will be very valuable to you 6 months down the road when you get some free time or your ADD switches to that project and you try to remember what it is this was suppose to do.
I just found out recently that writing specs is really the thing I need to get my projects done.
I've been a bit like you, tons of projects, jumping from one to the other and never getting things finished. Until about 6 months ago, when I started to actually write specs and have a kind of roadmap for my projects.
All that I can say is that, it actually works, because you break your projects into smaller steps, just like a race with checkpoints, and when you start to mark the checkpoints as done, it feels good, addictive and your focus will be on the finish line.
This way, you get to keep only 1 or 2 projects at the same time, but actually finish them. And of course, you have the extra and pretty valuable bonus of keeping up with the project even if you don't touch it for about a month or more. The specs will always be there to remind you of the goals and purposes of your project.
This is just my personal experience, and I believe that you should give it a try. Hopefully it will workout for you too.
I've been able to do some hobby projects and finish some of them. I try to finish them all but some i just cant muster.
The reason i think is that the amount of details that are needed to finish a projects are so many that it goes from a passion project to a chore of a project.
What helped me finish most of mine is that they stayed a passion until the finishing touches were left. So i just plowed through them.
Will a spec help, to some degree yes. They get you further into the project but almost always there's a point where the passion fades and you look for the next shiny object.
It doesn't work for me! Infact whenever I'm writing up specs I'm generally making the projects even bigger, and less likely to be finished.
Sometimes the best way to do it is to just do it.
Ze Frank explains this much better than me:
http://www.zefrank.com/theshow/archives/2006/07/071106.html (video link with swearing)
EDIT: Just to add. If you are finding you want to leave your half-finished project for a new, grand idea... do it! Don't look back!
Completion is not a requirement for your own pet projects. Nobody will blame you for not finishing stuff that barely anyone else would even bother starting.
The reason you started was because of passion. That is very important. You should not force yourself to 'slog through' in your free time. You will drain your passion which is your most vital resource.
I usually write a first set of spec when I get started.
I'm also a big fan of paper thinking, so I'll draw screens, UML, diagrams, flow charts, design elements... It's just a matter of defining the scope of your project and be able to watch what you had in mind. It really helps me think.
These documents will be my specs for the whole project. I will add others as I go, but I'm not trying to maintain the old ones as much as I would have it it was a work project: I know where I'm going and I can keep track of the changes looking at my code.
Of course, some of my hobby projects are done collaboratively. In these cases, I write down more specs in order to have a better communication with my team and I try to keep documents such as DB Diagrams up to date.
I also have several hobby projects that I have not finished. I have about 10 and have written a specification for exactly one of them, the largest in scope (also a game).
I have not finished either the ones without specifications, nor the one with. I think this is because I never publish the work or show it to anyone so it remains full of bugs and never 'finished.
I suppose that this means that regardless of whether or not you have a spec, it will not affect the success of the project as much as other factors, like having the time, motivation, help, and having confidence.
The single best thing I've ever found to help move towards completion is to have someone else working on the project with you. Find a friend (or two) who is interested in the same thing and design/code it with them. Not only do you have someone to bounce ideas off of, but you've also got someone to motivate you, not to mention progress is twice as fast so you'll hopefully finish before you give up :)
Of course, it requires source control, but you were already using that for your projects, right? :)
Do you want to finish them?
I think it's reasonable to never finish a hobby project. You can just keep working on it as long as you live. Aciddose has been working on his virtual instrument xhip for years, stubbornly never getting to 1.0, making the instrument patches people program worthless from one release to the next. Yet he and the users of his softsynth seem to be having a grand time.
Maybe if you just aim for a "release" and not being "finished" you'll be more satisfied. Betas let you keep dreaming.
Yes and no. I write notes in a notebook as I'm thinking about it, and add to it as I implement it. It is a somewhat different process from work projects where someone else may have to see the spec.
I finish about half of what I start.
I've helped with development on a range of systems from safety critical avionics to throwaway personal projects like a Sudoku solver. Obviously with the avionics systems, specifications were critical to the safe operation of the system and to prevent killing somebody, but I've never bothered with my personal projects.
I think this is because specs are generally boring to read and write. Joel wrote an interesting article about this, and how to make them better if you do write them:
Painless Functional Specifications
Unfortunately I haven't had the guts to try making my specs more fun to read at work yet.
Maybe intead of writing specs you should try working on some projects for or with other people? That could provide some external motivation. I do some web devleopment for my cousin's drive in theater, and if they need a feature they won't stop asking me about it until I finish it.
The single biggest piece of advice I could give you would be to get something out there - make the spec for your first version small enough that you actually feel you can complete it, even though it won't have nearly all the features you want.
Once you get something out there, the pressure from users of your software will be enough to hopefully keep you going on it. It also ensures that the direction you take in development is the same direction your users want you to go.
If you don't actually get any users, then don't feel so bad about dropping the project - if nobody is interested, it probably isn't worth pursuing.
If pressure from your users isn't enough to keep you focused, then open source it. If there's enough interest in it, somebody else will pick it up where you left off, and you are free to move on to bigger and better things.
Unfortunately, after writing specs for the core of the DIFL engine (don't bother looking it up, as there's no trace of it outside my home systems), I still didn't finish it up.
Short answer: developing specifications for a hobby project is neither necessary nor sufficient to guarantee completion.
That being said...
I keep an engineering notebook for all of my personal projects. I use the notebook to capture all sorts of things about the projects on which I work. This includes project motivation, valuable resources leveraged during the project, things developed over the course of the project that might potentially be reused later, key insights gained, etc. etc. It also includes, more to your question, specifications for most of the projects. I employ an agile/lean approach to creating these specifications which, for me, is compelling from a cost/benefit perspective.
btw...I have many, many personal projects that did not culminate in a complete working system. Some of these I might get around to completing 'someday maybe'. I consciously chose to stop working on some of the others because they had served their purpose (e.g. introduced me to a new technology, helped me better understand a language feature, etc.) Continuing to crank away at projects like these would have led to diminishing returns so I chose to reallocate my time to projects I felt were higher leverage.
The real question is: what is your hobby? Is it finishing a project, or tinkering. If getting the last ten yards is a chore, you have to decide if it's worth it to you. Writing detailed specs will work; so will self-flagellation if you're into that sort of self-discipline. Nothing will make it easy if it's against your make-up, so you have to decide whether the end-goal is worth anything to you.
And, just to demonstrate that there is nothing programming-specific about this point, you might really like this guy. One of the main points in his work is that conceptual artists, such as Picasso and Da Vinci never really cared about the final execution--the idea was everything, and, having asserted it, they were strangely content with someone else finishing the actual work or leaving the sketch unfinished and unpublished.
I'm not sure that writing specs is the solution to your problems (or mine which seem similar) however in the case where I want to make something more than a throwaway experiment there are a few things that help me slightly without taking the fun out of it.
Specs really are quite tight and should be technical but for a hobby approach you could write up a little bit of something similar much more loose that outlines some of the things you would like to feature and shows how they fit together in a sort of design draft. Though not as detailed or restrictive as a proper spec it might help to keep the tinkering leading in the right direction.
Secondly you could break it down and depending on your time allowances maybe add a few goals in. If you focus on building one part of the project as a time breaking it into subprojects that can be linked together at the end, it gives a feeling of progress as you move from part to part rather than feeling like you have been working on the same thing for ages and can't be bothered any more. It works if you tick it off on a list, since usually it has to happen atleast mentally anyway.
In saying this if your goal is to play with certain concepts and not actually create a final product then you probably won't because you aren't working towards it. One way might be to take the above mentioned idea of breaking it up and then find a way of adding something personally interesting into each part that bores you, maybe trying to add a challenge into it or something.
I'm not particularly experienced still learning, but this is how I keep my tinkering together(sometimes unless I hit a total block cause by inexperience) and how I've approached many multimedia and web projects on a hobby basis in past years. Though the guy who said open-source it when you get bored and let someone else pick it up, that was a good idea if you want to see your code used but have satisfied your personal goals.
I have much the same problem. One thing I've noticed that HAS helped though, is lowering my ambitions. like WAY WAY low. Writing a spec is one way to reign in the ambitions, if you have some kind of limiting rule for the spec, like "The spec can only be one page", or "the spec can be no longer than 300 words long", or "Spec only something that I can get done in one day of coding". Getting the balance right can take some practice. If you go with the last limit, you can impose the rule of MANDATORY dismissal of the project if you can't finish it in one day.
The nice thing about this, is it limits you to achievable goals. This might sound really stupid or wrong at first. Or maybe it sounds reasonable, but you just can't help it, you wanna do amazing things, not ordinary things! Not small things that you can only get done in a few hours!
but keep this in mind:
“A complex system that works is
invariably found to have evolved from
a simple system that worked. The
inverse proposition also appears to be
true: A complex system designed from
scratch never works and cannot be made
to work. You have to start over,
beginning with a working simple
system.”
—John Gall
It is SO MUCH easier to make that ambitious project, if you already have a FINISHED and WORKING project to base it on. Then the "more complex thing" CAN be a project that fits in a day. This is the ideal and philosophy I'm working towards, because I think it has the best chance of succeeding. Looking at past successful projects, the vast majority of them evolved in this way, whether it was intentional or not.
What helps me a lot is to split a new feature into small tasks that could each be done in an evening hacksession. So if I have time, I simply pick one task from the list and just finish it. This is often enough to get "in the flow" and do "just one more".
I do this only for one feature at a time so I don't get distracted by all the other cool things I could add to my application.
I constantly write specs for my projects, in work, at university and outside in my free time. The biggest weakness of a programmer is his/her memory, so I find it good to keep myself busy during my thinking time by writing down my every thought into some sort of structured document. Before you know it you've written a full database schema or have a Requirements Specification.
At the moment I'm working on improving my SQL skills, and I've been spending a lot of this free time between writing queries writing down my experienced. After a couple of tweaks I had a decent document outlining what needed to be done.
I think the core problem is not the lack of specs, but rather that finishing something (anything) is hard.
It is hard work. It may seem as if your program is 90 % done. But doing those last 10 % (rooting out all bugs, getting the application to release quality, writing documentation, etc) requires as much work as the first 90 %. And if you want to be serious about marketing your program, answering support emails, fixing other people's bugs, that's more work still. And perhaps not the kind of work you are most interested in.
It is also hard mentally. An unfinished project has unlimited potential. It is an empty canvas where you can project your unbridled ambitions, lofty ideals and revolutionary thoughts. Once it is finished and made real you have to see it for what it is. Limited. Flawed. Never as pretty as the idea that spawned it.
That said, finishing something can also be very rewarding. You learn a lot, get a reality check on your ideas, the satisfaction of having completed something and you get to see what other people think of your work.
Some advice:
Make sure that you really want to finish the project. I.e., that the rewards are worth all the hard work. (If not, then accept that fact and remain a happy tinkerer.)
Find ways of motiviating yourself through the "boring" parts. Specs, maybe, if it keeps you focused. But find whatever works for you, whether it is ticking of todo-items, rewarding yourself with a cookie or dreaming of fame and fortune.
Release early, release often. The more you save for a "big release" the bigger is the chance that that release never happens.
First release, then rewrite. When you feel the urge to do a major rewrite, do a release first, then do the rewrite (if you are still up for it). Software is never perfect. If you strive for perfection without any pressure to release your half-baked (but existing) code, then you will never be done.
Most hobby projects of mine don't really get finished either. As long as I'm working on something and learning though I don't think thats a problem. Currently I'm not writing specs, but I am practicing/training TDD. I bring it up as I write tests that are the specs. Some days I'll sit down and just create a bunch of tests outlining what the software should do. Some days I make those tests pass. Its enjoyable in that I don't have to keep the code all in my head, and at any point I can sit down and make further progress by fixing the broken tests. Things just work, its kind of surreal.
Joel's article about the Evidence Based Scheduling works for me. Though I implemented it differently.
The idea is to break the project into small tasks and give estimates, then make a forecast when your project will finish based on the time the finished tasks took to finish them.
You may think your project will take years to finish, but actually from the estimate it's just two months or less. If you work more and finish tasks quickly, you will see the finish date coming earlier.
I think the most motivating thing to proceed forward is seeing the goal coming closer you run towards.
Plus: create something you will use later. Using stuff gives you incentive to improve it later.
I am fresh out of College (graduated in December with BS in Comp Sci). I have been working for a very large (40,000+ employee) company for over two years. My job is as stable as anyone could hope for. However, I am always bored, they cannot keep us (developers) busy. I am thinking about apply at some local contracting companies and try out contracting. I have been told that I could make a lot more money as a contractor and even more if I was willing to travel. I have been told that as a contractor I would basically be constantly coding, no BS meetings about project charters and stage gates, and that I would learn more in a year than I would in 10 years at my current job (this I believe since we're using java 1.4 and our brand new laptops have windows 2000 on them... lol). I just want to know what to expect if I decided to go the contracting route, and if traveling is worth it. Since I don't have any kids and this seems like the best time to do something like this.
What have been your experiences with contracting? How do the mechanics of travel as a contractor work (what is paid for, do you work 4 10 hour days... etc)? Will I really be mostly coding? Will I really gain valuable insight and knowledge of the IT world?
I can't speak for your situation in particular, but my company recently terminated all of our contractors as part of our cutbacks, and many other companies did the same. Most companies have hiring freezes, where they will not take on new employees at all, contractors or not. My friends that were working as contractors all lost their jobs, and are generally having a difficult time finding new positions.
If you are already in a steady job, I would say that now is not the best time to drop it and try switching to the life of a contractor.
You expressed an interest in learning new technologies, so if your company doesn't keep you busy, and you're "always bored", why aren't you using that time to read up on the things you're interested in?
I've been migrant IT labor for 30+ years.
"I have been told that as a contractor I would basically be constantly coding"
False. You might wind up doing a lot of new development or a lot of maintenance. Depends on the contract firm's relationships.
"no BS meetings about project charters and stage gates"
False. The contract firm has to land the gig. As a contractor, you write a LOT of proposals that get shot down in flames. In-house initiatives are quietly morphed into something else. Out-of-house initiatives turn ugly -- the contracts are fired -- there are lawsuits.
"and that I would learn more in a year than I would in 10 years at my current job"
True. If you pay close attention and take careful notes. More importantly, if you've done your homework outside the workplace. I've been to a fair amount of training, but I think that 75% of the skills I use regularly (Java, Python, DB Design, Architecture, Apache config, HTML) I had to learn on my own.
"what to expect if I decided to go the contracting route"
Parts of it are bad. Parts are good. It's a job -- that's why they have to pay you to do it.
"if traveling is worth it."
Let me list the benefits -- Skiing in Anchorage, Skiing in Utah, Diving in the Florida Keys, flying the entire family first-class to San Diego, using Hilton Honors points to stay at the Waldorf=Astoria.
Let me list the problems -- kids who got into serious trouble at school. Missing family time because of travel. The unending stress of air travel, including the TSA security theater setups everywhere.
Nearly everywhere I've been, we've hired contractors to work on the old, legacy stuff that our employees have forgotten or otherwise don't want to work on. Nobody is going to hire you in order to teach you things - you won;t be around long enough, so they will only hire you for your current skills. Quite a few contractors complain about having to keep their skills up to date, at their own expense.
You'll also get less time spent in meetings (well... maybe not, you'll be there to be told what they expect of you), but you'll also have to manage your own accounts, and invoice the client, and then chase up payment.
So, don;t think contracting is a magic route to fun coding with the latest technologies. Its probably the opposite of that. What you want is a different job.
The grass is always greener on the other side of the fence.
You're stuck in a large company with all the large company management bureaucracy and strict job roles that goes with it. If you contract for a large company guess what you get? However you can choose who you contract for (if they're happy contracting to someone with two years experience). To me it sounds like you actually want to work for a small company developing software in a more agile fashion, and that's a more risky move!
Note that with contracting you'll go from project to project, and having to pick up the client's systems (code, models, databases, workflows, etc) from new each time, often with very little assistance. If the systems are in any way mature, then there will be lots of cruft to sift out - if you're lucky it will be documented! So every time you have a problem, you will have to get on the phone to them or find them (a difficult task on its own) to get the knowledge you need.
I've been contracting/consulting for just over a year and am really enjoying it. A few of the perks:
money is good.
changing projects fairly often keeps the boredom levels down.
working from home rules.
because you are an expensive resource relative to other employees, the amount of administrative fluff and pointless meetings is minimal. The client wants you to spend as much time as possible working on whatever it is you've been contracted to do.
I'm picking up new knowledge much faster than when I was a normal employee. I suppose its related to changing projects often and working with a range of people.
I strongly disagree with the sentiment that contractors get boxed in and have to teach themselves new skills in their own time. Perhaps this is true for some domains but my experience has been the absolute opposite. One thing I have noticed is that if you do a good job with a project, you'll be asked to look at other projects even if you have no experience with the technology in question. Being trusted as competent and honest is far more important to most employers than a '5 years experience with J2EE' line on your resume.
That said, its not all rainbows and butterflies. Some of the downsides:
getting a mortgage is going to be really hard because of the lack of permanent employment.
whenever there is a downturn, you'll be the first against the wall.
if you are working on a fixed cost basis, you'll have to get really good at project estimation or risk lots of unpaid overtime.
taking on multiple clients at the same time can be a horrible mess unless you have excellent time management skills.
Overall, I'm really enjoying it and for me the pros far outweigh the cons. I think I'd only go back to being a normal employee if I had a family and couldnt warrant the risk of being out of work for an extended period of time.
As a contractor you do tend to be less involved in meetings, in my experience. But you spend a lot of time teasing requirements out of clients and waiting for responses on things. As you're not in the day-to-day flow of the organization, you have to work a lot harder to understand what's going on.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have my moments of inspiration like many others -- most of them bad, with a few diamonds in the rough. Is it possible to monetize those diamonds with stakeholders or entrepreneurs without actually being the person to handle development and technical? Any avenues that you can recommend would be appreciated.
Yes it's possible but also you should consider this:
From Getting Real
Awful idea = -1
Weak idea = 1
So-so idea = 5
Good idea = 10
Great idea = 15
Brilliant idea = 20
No execution = $1
Weak execution = $1000
So-so execution = $10,000
Good execution = $100,000
Great execution = $1,000,000
Brilliant execution = $10,000,000
To make a business, you need to
multiply the two.
The most brilliant idea, with no
execution, is worth $20. The most
brilliant idea takes great execution
to be worth $20,000,000.
That's why I don't want to hear
people's ideas. I'm not interested
until I see their execution.
However I think it's possible make a draft and show it off to seal a deal.
It's possible, but consider this: how much value is there really in an undeveloped idea? You're not the only one out there with great ideas you can't implement.
Having said that, if you really think it's new and original, you might as well use the broken system to your advantage and look into patenting it.
Ideas are a dime a dozen.
Getting them out the door is where the real work is.
There's a lot more to a new product than just an idea and software development. Frankly, these are two of the easiest parts. Marketing your product and getting people to actually buy it - that's the hard part!
Depends on the nature of the idea, but if all you have is an idea, but no work, you're unlikely to find a buyer who will pay you a decent amount.
No.
Everyone has ideas. They are a dime a dozen. Less than a dime a dozen.
Ideas without implementation are wothless. You can neither get, nor deserve, any money without anybody doing any work.
Start a business, get a business loan to fund your business early on. Pay people to work for you developing said idea. Once you have early prototypes then you can start looking for outside funding and try to make returns on your initial investments.
It is possible to sell an undeveloped idea but probably almost impossible to protect it. Consider this, no matter what you do competitors are watching for quick solutions.
The only real means of protecting a niche in a market is to be the best at it, to gaurentee that a replication of your product will be a waste of money, because it will pale in comparison, due to your head start in developing the product.
In short if you can't be the best at your idea, it will be replicated and you'll be outcompeted.
Therefore,
If, and only if, you're convincing (or crazy) enough to find someone who can competitively produce your idea will you be able to monetize the idea.
In general I would say no. Investors will at least want to see a prototype.
If your idea is amenable and you are willing to do some work, you may be able to take your idea and sell it as a consulting engagement to a company. You can structure the agreement to keep the rights to your software. I've worked on a project like this before.
Of course, you could always build a time machine and travel back to 1995 where you could sell ideas without having anything built.
You said that you have potentially money-making ideas, in moments of inspiration, and that most of them are bad. I suspect most of us are like that.
How do you tell which ideas are bad and which are good? It's usually impossible to do so without trying them out. If you're willing to go out and work on one, you're at least showing that you have confidence in that one. If you aren't willing to, why am I to have confidence in your idea? Give me some reason to believe somebody (perhaps you) thinks it a good idea. (Alternatively, you could try patenting it, which last I heard cost about ten thousand dollars or more in the US, but that could also turn me against the idea.)
How do you handle a situation where I might have had the same idea, and for whatever reason didn't pursue it? I'm not interested in giving you money if I implement an idea I came up with independently. If you tell me the idea, I can always (honestly or otherwise) claim I had it also. I'm not interested in signing anything that restricts my actions in the future (like the ability to profit off an enterprise without cutting you in) unless I get something for it. I'm also not interested in putting myself in the crosshairs of a lawsuit if I start a business and you think it was from your idea. I have no business reason to listen to your idea unless I already have some confidence it will be profitable to me, and for that see the paragraph above.
Ideas come to everybody. I have ideas. You have ideas. Why should I pick an idea that gives you a cut of the profits, when I can pick an idea I had myself? Sure, I probably overestimate the value of my own ideas, but you probably do also.
You see people making lots of money for no particularly good reason, an author cleaning up on a book that's not all that good, a financial analyst getting millions while bankrupting his company, that sort of thing. What you don't see is that those people put in a lot of time and work to get into that position, where they could profit unfairly. If you're willing to put in that effort, maybe you can get an undeserved profit too.
So, if you have an idea that could be worth millions, get a start on it. Don't try to profit from it without something to show, preferably something that shows off advantages without giving away the whole idea. That shows that one person, at least, has some confidence in the idea. It puts you out in front, if only slightly, and demonstrates that you're probably the logical person to keep going with the idea. It allows you to discuss possible ways to exploit it without giving away the whole thing. It allows me to save face; rather than admit that you have better ideas than mine, it allows me to finance you on the basis of something tangible. (Never expect somebody to pay you just for being smarter than they are. If you are, they won't want to admit it. If not, well, why should they pay you?)
I run a small software shop and over the last 20 years I've had dozens of people approach me with ideas. Most were users who were thrilled to simply see their ideas brought to fruition. Some were convinced, as you appear to be, that they had the "next big thing" and just needed a programmer to make it work. One guy actually sent me a "non-disclosure" agreement that would have, in essence, given him ownership of everything I developed in our field forever after signing the NDA. His "logic" was that his idea was so wonderful that anything I ever thought of after hearing it would be colored by his brilliance! Obviously, I threw it away and he faded into obscurity.
My take is that ideas are free, period. If you don't have the wherewithal or initiative to turn your idea into a real product, or even just a prototype, then you simply have no claim that anyone else need honor. My apologies if this sounds harsh but I've simply been at this too long to buy into the proposition that the people who do the actual work should owe anything to people who just free-associate.
If you do put in the effort to make the idea real, then you are owed the full protections of the copyright and patent laws to the extent that they apply.
First : You should discuss your idea with people you know who are good in that technical domain. They will tell you if 1. The product is worthy 2. There is nothing like it in the market already.
You could then try venture capitalists with your market analysis. There you might have to justify as in why you don't want to develop the product but want the money up front.
There are people who would buy the idea but the chances are slim if there is no prototype at least.
Genius is 99 percent perspiration and 1 percent inspiration.
-- Thomas Edison
If you don't have the time to develop your idea, you might have to be satisfied with giving it to others and watch it flourish. Or else, found a company, hire a CTO and CEO, and offload the implementation work. You might then have to be satisfied with only a small fraction of the company.
Professors give away their ideas to "student entrepreneurs" all the time, trying to get them to actively perform implementation work. The professors would co-found and then provide consultation to the company.
Yes, it is possible to sell idea/s. But before that just google it if your idea is already implemented or already stolen by someone else. Its a huge world with common thoughts. Every time google disappoints me by showing number of results of my (so called unique) ideas. But keep trying, you may be Genius.
Get yourself a sales guy that has no problem selling "vapourware".
Then when he's sold a version of it, code like mad to get it done.
Unethical, maybe, but if you can pull it off, it'll get a startup up and running nice and quickly.
How do you know it's a good idea? Evaluate your idea, assess the market it will play in, identify experts or talent that could implement the idea, create a rough marketing plan or launch plan, make some blue sky revenue guesses, and figure out the next smallest possible step towards realizing the idea (that is, plant your first milestone).
Now bounce all this around friends, and business people asking for evaluation. Take it to your local Small Business Developer Center and see if they have advisors that you can meet (most have some type of network of retired executives).
If (and it's a big if) you have the capability to implement the idea than yes, you might get angel round funding, a business loan or a team of excited volunteers willing to sweat for equity. That first milestone is key for some investors - "Fund me to this point and then we'll sit down and look at what we've got and re-evaluate and hopefully decide to continue funding."
Ideas are cheap. Implementation takes money, time and especially effort. And it's effort that is valuable.
If you just want to jot down your ideas and sell them, just write a book of ideas.
I would probably buy your idea if it would be so great.
For me ***the lack of idea is the issu***e, I would stand up for its execution (after its evaluation of course).
Not sealing a deal here, but startups would not be able to pay for the idea, instead they would be able to make you co-founder, stakeholder or similar when they will start implementing your idea.