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 11 years ago.
I'm wondering what you do as a programmer that's not programming but necessary for your task (eg: local setup, server setup, deployment, etc). I'm curious to know how many non-programming related tasks people are performing.
For example, when on web development projects I often:
Install servers
Manage user right/access to servers
Perform backups
Configure IIS/Apache
Setup FTP sites
On non-web projects I often:
Write build scripts
Setup source code management tools/procedures
Probably more stuff I'm not thinking of
Some tasks are more related to programming than others (such as writing build scripts) but others fall outside of my area of expertise (domain setup comes to mind). Just interested to know how many people perform tasks in their jobs that are not programming related.
The sad reality is that non-technical people look at technical people and expect them to know everything that is technology related, not understanding that there are specializations within technology which we might know nothing about.
I often think it is very much like a doctor that specializes in a particular discipline. All doctors have a baseline of knowledge in the medical field, but will not know the specifics of other specializations (a cardiologist will not know as much about anesthesiology and vice versa).
So while I think it is unreasonable for people to expect technologists to know everything, I do think that it is reasonable for them to expect that we know something when it comes to technology.
I think a more important facet of this question is how much one is expected to know about the specific domain where they apply their skills (finance, manufacturing, etc, etc). I think that is incredibly important, as having that domain knowledge makes them much more valuable as a programmer, as they can understand the problems on a deep level, and as a result, provide more comprehensive solutions for them.
Expected? Almost nothing, but everyone's always really happy when you know more.
The more you know outside the narrow confines of programming, the more valuable you are to your employer.
Things that have come up for me:
requirements gathering
writing use cases
evaluating test plans
negotiating with vendors
tax law
revenue recognition rules
ideas about how users behave
basic economic theory
usability guidelines
differences in consumer behavior in different countries
system administration (being a full on sysadmin)
database configuration, optimization, setup (basically being a DBA)
monitoring systems
networking principles and techniques (you'd be amazed how handy a packet trace can be when debugging something...)
being able to evaluate a business plan written by someone else
image manipulation
how to diffuse a situation and avoid arguments
how to corner someone and make them to commit to something when they don't want to
how to choose battles
I think the non-programming skill I use the most in my programming job is writing. It's really crucial to be able to explain ideas, designs, algorithms, and so on, and you can never count on being around to do it in person (or having the time). I spend a good amount of time at work writing up design documents and other documentation so other engineers can get their heads around my code and algorithms. So I'm really thankful that I had good writing classes in school and can put a sentence together. :-)
Probably depends on the size of the company you work for. As someone who has worked mainly at small to medium sized businesses, I've also been responsible for:
database creation, management, and tuning
supporting the internal applications I launch
managing website certificates
setting up external hosting
and I'm sure there's more as well
Well, since a programmer's primary tool is his computer, I think it's fair to assume some expertise with it. Most of those sorts of things you've described are difficult for someone unfamiliar with computers, but pretty easy (even with little prior experience) for someone who understands the domain and knows how to find and read documentation.
In a big, well-organized business or project, I'd expect someone who was more specifically familiar with those sort of administrative things to take care of them. However, if there's not enough of them to warrant a full-time job, then I don't think it's unreasonable to have anyone competent work on it; and programmers are probably at the head of the queue in that regard.
I find the vast majority of "bugs" discovered by users are configuration problems with the systems on which the application is installed. Having developers that understand the common machine and network setup errors is very desirable.
For example if an application sends email as part of its operation its useful to have developers knowledgable in DNS and SMTP configuration.
Of course it depends on your size of business, large organisations can probably shield developers from this by using other specialists.
I realized I'm never hired for the actual job, but as a problem solver. Whether I figure out what's going on, and fix it through code, or software, or something on the network, this seems to be the main perception of what clients want.
This will vary greatly depending on where you are. I've worked with people who know none of this stuff, and people who are experts.
Knowing this will help you greatly. In general it's always better to understand the environment your code is running in. Not understanding the context leaves you somewhat helpless.
Additionally there are often bugs that are not code related but configuration related, for example a page not showing up because of the apache configuration. You're very handicapped in debugging if you don't understand the environment.
People around a work place probably expect a programmer to be their IT HelpDesk guy... it happens around here to me. argh.
Where I work, all developers are expected to be able to use Subversion and have to be able to setup and configure Apache and Tomcat on their PC.
The biggest challenge is not the technical issues associated with getting the environment up and running but the domain knowledge required to effectively develop software in a small shop. For me, I work on a lot of different projects from a variety of sources in a mostly isolated development environment. This means that I need to come up to speed on the domain of the project pretty quickly in order to be effective in developing a solution. In the past I've worked on print accounting solutions, active directory management, research survey databases, and currently a quasi-CRM solution for a charitable organization. I wish I only had to know the nuts and bolts of setting up my development and build environment.
It often depends on the size of the company. In a little company, you have to know how to do everything, including systems admin, and network admin, even if your job is focused on programming.
In a big company, you get to see a little slice of the universe, and they often don't like you peeking outside of your box. Not only do you not need to learn everything, they're often unhappy with you if you try.
However, the more you understanding about the machines, how they work, and how they function in an operational environment, the easier it is to diagnose problems and write better software. The more you understanding about the domain you're writing applications for, the better you are able to differentiate between the users needs and their desires.
One of the coolest things about being a software developer is you have a life long excuse for sticking your nose into both the technologies and the various business domains. If you've shifted around to a few different industries, you tend to become loaded down with all sorts of interesting tidbits. There is always more to learn ...
Paul.
It's good to expose yourself to other technologies, but I really think it's a bad idea for you to not fully disclose the fact that you aren't experts in those areas (esp. domain setup). I've worked with people who thought they could do it all but ended up doing those tasks so poorly that with all the time (and money) they've spent trying to get it right, a consultant would have been paid for several times over.
I've worked at a company where I was responsible for everything "related to a computer" including the domain, PCs, database, custom software, builds, MS Office, PowerPoint, Quickbooks...; a mid-size company where it was development and builds; and a large company where I focus solely on the .Net code for my project (someone else handles the database and another handles reporting).
The mid-size company has been the best experience so far (pretty new at the large company) where I was given enough responsibility to feel useful and had easy access to everyone else to ask questions about those other tasks.
You are not alone out there. The position I signed up for was "ASP.NET Web Developer"... However, my job consists of:
Windows Server Administration
Limited Linux Administration (running
top to monitor CPU utilization and changing apache configs)
LDAP Administration / Tuning
MS SQL Server 2005 Administration /
Tuning
Database Development
Crystal Reports Developer
Perl Scripts
C# Win32 Developement
C# / ASP.NET Web Developement
Managing User Access Rights for
Windows Servers
Limited Network Troubleshooting
Being in a company that is constantly striving for supreme "Operation Effectiveness" my task list only grows by the day. I did not make up that list either. All of the items mentioned above, I have either touched or supported in the past 3 years I have worked in this company.
That being said, in a good development shop, you should have one specific task. As the saying goes, Jack of all trades ... master of none.
This depends greatly on what you're programming. If you're doing low level device drivers, it's vital that you understand the underlying hardware. If you're doing a standalone Java app, the better you understand the JVM and libraries you're using, the better - but it isn't strictly necessary to know a lot.
In general, the more you understand about your system environment, the better. How much your peers and management expect you to know depends on them.
Ignorance will, eventually, be punished. If not by your peers and management, the world will do it. Check any week's headlines or RISKS digest for examples where ignorance of the system environment cause software failure.
[rant mode on]
Ha, the curse of Excel and Word.
Outside work - particularly friends and family but sometimes when consulting or delivering software too, any and all non-technical people expect you to understand these. There's that internal groan when someone asks you across to have a look at a small problem they're having with some facet of Office. And because it's a client and you want to appear helpful you agree.
There's just this blanket expectation that because you're a developer you have an innate knowledge of configuring spreadsheets, fixing Word templates, and any and all other office techie tasks, and furthermore you can cast your eye over some badly configured Office mess and instantly diagnose what the problem is.
I can only just about manage to put together a spreadsheet to schedule my reoccuring invoices and set up a Word template to write them. I regularly tell people that too - but no-one ever listens.
It depends a lot on the type of software you're currently developing
For example, when I was working on software for a local government, I had to learn things like
What are the rules for registering animals (pets). What are the types of registrations, what discounts apply, what are penalties for not registering on time
How are council rates calculated. How are rates raised yearly (actually, the algorithm for raising yearly rates and its implementation was the most complex task I met so far).
How are building permits issued. What types of inspections can be performed. Who is involved in the process of issuing a building permit (owner, builder, architect, officers etc.)
How often are water meters read. How are water meters assigned to properties, how many dials are on a water meter, how to detach a water meter from one property and to attach to a different one
What are different pension types. What are different discounts that are granted depending on a pension type.
What are different types of receipts. What different types of terminal printers (those that are used to print small receipts) exist and how to print to them.
What are properties, strata children, what are rules for dividing properties into 'parcels' ...
Well, that's just part of non-programming stuff that I learned during the 2 years on the project. The most unfortunate thing here is that now that I moved to a different company, there is very little chance that any of this knowledge I will ever use.
My job title is "Senior Software Engineer". In point of fact, for most of the past several years, I did fairly little software development, but did do a lot of:
Systems & web administration
Static web page development with HTML (I don't consider that programming, although I have done PHP, CGI, and JavaScript).
As others have said, help desk sorts of stuff, although not as much as in the past.
As a "task leader", I'm expected to have some people/management skills, although that usually devolves to writing monthly reports. I also get sucked into CMMi stuff from time to time, which in an ideal world might be somewhat relevant, but is usually just record keeping so the employer can bid on new contracts which require it.
Working in science lab, there's a need to know some of the science, especially if you want/need to work on the code doing the scientific calculations.
Working in a (U.S.) government facility, there's lots of paperwork and a need to know lots of government regulation (e.g. Freedom of Information Act)
Fortunately, I've recently made an internal transfer where I'm doing more development work and less of this other stuff!
Personally, I find that knowing more is always good, it paves the way to the next level. The hardest things in life is at the integration point. Literally. People focus a lot on specializing, but don't forget that you need people who can straddle both realms.
Related
I work in a big organization, spread around the world, about 17,000 people. Have to ask for money wayyyyyy in advance for projects before even really knowing what they are.
So we're redesigning an old intranet. Spending a chunk of money we have on user research and UX design phase. More on the 1.0 and piloting it and dealing with content migration and all that fun stuff.
Any ideas (insane ballpark here) about how much $ to ask for the next phase (rolling it out, more testing, actually replacing the legacy intranet)? I know details are sparse but there are some silly budget deadlines that require me to pull a figure out of thin air before I even really know what our end users want. If I don't come up with a number, we get nothing and have to hunt around in various budgets to get cash.
What would you throw out for low / medium / high numbers here? Low being open source, out of the box functionality, not insane customization, no more UX research beyond what we're already doing, and off we go. Medium being a nicer step up, and high being paying someone like Igloo $400k to use their out of the box platform, and then another bunch of custom plugin development and design work on top of that.
Right now I'm thinking 250k, 500k, 750k. Am I in the right ballpark, or am I over in some other arena that's not even in the same league and hasn't seen a baseball game in years?
As you've all but acknowledged, it's an impossible question to answer. You are constrained by an illogical system which seeks to reduce risk by increasing control in the mistaken belief that accounting for all spend in advance will increase return on investment. Your challenge is to learn how to play that system to your advantage, secure your funding and achieve the freedom to deliver your project with minimal interference.
Support
Fortunately, you are the best-placed person to do this. You have the best understanding of your organisational context and if you look at broadly similar (global, cross-functional) internal projects, you can get a good idea of how these projects are regarded and how they secure and maintain support and funding. Talk to colleagues and learn what you can. Ultimately you aren't looking for a right answer - you need to know what constitutes an acceptable answer and how to proceed when your guess proves to be "wrong".
Start looking externally to learn what you can about projects in similar organisations. Listening to others' experiences will give you a better understanding of potential risks, so dig deeper than the run-of-the-mill success stories. You might consider attending conferences, intranet-focused meetup groups and participating in online communities.
Vision
What is important is that you have a vision for your intranet project. As you go on, this vision may change. You will hear lots of assumptions about what people expect to be on the intranet. It's great to read you are conducting UX research as it's vital to understand what people actually need and use.
Needs
A guest presenter at a recent intranet event I ran showed us an intranet she'd built in-house over a five year period which was designed solely to help employees do their jobs effectively.
There were no generic calendar tools, no pages of content that no one ever looks at and no fashionable social features. Instead there was a lean, focused business tool, written in PHP, on which she'd spent GBP20,000 each year.
Equivalent value? Probably a month of Sharepoint consultancy.
It takes careful leadership and communication, but once you stop trying to deliver mediocre generic solutions based on what everything thinks "should" be on an intranet, you can ditch out-of-the-box tools and start focusing on your users' real needs.
i have seen people to more concerned about the type of work they do. they think system side work is better compared to application side. so i wanted to know the pros and cons of both.
please i didn't find the proper answer anywhere so i am asking here.
System Side Pros:
Get to do all of the cool things that we learned in computer science: parsing, searching, sorting, threading, date/time handling, computations.
Interface specs more limited easier to understand and wrap our brains around. Our systems talk to other systems and programmers, not those really ambiguous regular people.
Puzzle solving with well defined puzzles.
System Side Cons:
Less interaction with the real world.
Application Side Pros:
Large scale puzzle solving where the puzzles are often niether well defined nor do they have stable scopes.
Get to learn lots of business areas outside of our areas of expertise.
Get to learn how people and software interact.
Learn to abstract and model in such away that we can support an ever changing world due to regulatory changes, market changes, user desires.
Application Side Cons:
Project scopes are often not well defined.
I'm sure there is a lot more.
Better could mean "More Fun" or "Higher Status" or "Higher Pay" or "Greater Job Security" or many other things.
I have seen situations where the UI construction is outsourced while the core services are seen as mission critical and kept in house. So in that organisation it seems clear what is most valued.
As we get towards UI development the skill sets can shift a bit, the aesthetics and visual skills, concerns for usability start to be more valuable. Folks who work mostly on services and middleware may feel less comfortable in that UI space. Hence if you talk to the server-side guys they might say "More Fun here".
Maybe you could survey the job market and compare salaries of UI developers and server-side developers.
My opinion: there are fundamentally different mind-sets between working in "Application" and "Service". Some individuals feel much more at home in one or the other, and great developers in either have fulfilling careers. Some (but not all) developers seem to be able to seemlessly shift between the mind sets.
There is no universal "better" - for example if you are into UI development, sorry that's "User Experience" now isn't it? If your a UX wizard then you're really not going to enjoy working on development which focuses on things that tend to have very little to do with the front end user.
Development is a very broad church - although the majority of the core skills (fundamentally problem solving and implementing those solutions) are common the specifics vary substanially - games developers require a particular mindset that in places is substantially different to that of a developer doing line of business back office systems.
Within the same web application, front end client work in the browser can be utterly different to that required in the back end model.
Within almost every area there are going to be superstars who earn shedloads of money (this, I suspect, is the mythical "better") but most of us have to put our heads down and get on with it regardless of what area we work in.
Do what you enjoy...
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 months ago.
Improve this question
First a little about myself. I am not an experienced software engineer, architect or developer. I have done mostly small ASP and ASP.NET projects in C# for the last 5 years. I am pretty good with HTML and JavaScript. These projects were done when I had free time from my other duties which were not related to software development. I have now been moved into a software developer position. The company I work for is not a software development firm.
I am now working on a Silverlight LOB application with WCF and Entity Framework. I have been given little specifications for this project, just the 'make an application like X, only simpler so we don't have to pay for it', my boss doesn't check on my progress as often as I think he should, the project manager(a co-worker) will stop by now and then but we never discuss the specs, architecture, UI or business rules. I am mostly just asked when I think it will be done. I have had to learn Silverlight, WCF and Entity Framework to work on this project which is not a problem as I really enjoy working with these technologies. The problem is I am the only one in the company that knows anything about these and have no mentor/boss to discuss the problems and how they could be solved. I have been able to seek out one interested party in the company that has at least given me a list of some of the requirements.
I can't believe this is how software development should be done. I think the project managers should offer guidance and keep a closer eye on what is being done to prevent going in the wrong direction(but how can they in my situation since the don't know the technologies!).
Should I feel this way or am I way off base?
Thanks for listening.
What you describe is certainty not optimal, but it's extremely common, particularly in smaller shops. Some people find it rewarding to work in that kind of environment. It's not what the software engineering books teach, but that's why there are so many software engineering books.
If you want to continue working in this environment, you're going to have to supply all the discipline you rightly recognize as missing yourself. Write up a spec. Build a schedule. Share these with your management. Hold yourself to deadlines.
Share your concerns with your management; don't be shy about that. Chances are, they recognize the situation. Your boss doesn't check your progress? Publish your progress to him. Show him where you need to get to, how far along you are, and what's blocking you.
It'll be chaotic, no doubt, but you'll learn a lot.
Every organization is different. If they are operating in this capacity then you should adapt and make the best of the situation. It's either happening because that's how things are done and they are aware of it, or they don't know the wiser or don't want to invest to improve the process of delivering strategic/tactical projects.
In a perfect world everyone would have a robust Quality Methodology in place which would provide a framework for Project delivery and systems implementation. It's just not a reality.
Here are some tips to help you operate more effectively:
Identify your sponsors (the people who own the product) and determine the high level benefits and driving objectives of the business problem they seek to solve
Identify your stakeholders (who has influence and who has interest) and get them to communicate their needs as much as possible
Involve both sponsors and stakeholders in the process as much as possible or as much as they want
Capture what requirements you can from them through written form (email)
Provide opportunities for them to gain visibility into the delivery and to provide feedback
Your project will likely fail from your boss point of view. Because i'm sure you developing program not suitable for him. But you don't feel guilty. It's your boss' pain.('because you are good programmer). Sorry for so dark post :-).
The role of the project manager is not to know the technology, but they definitely should have a finger on the pulse of the project, so to speak. The real project management job is not to control the project, but rather to enable it. Either way, from your description, looks like yours isn't doing such a great job at it.
The other extreme is a process-heavy organization where meetings and committees decide everything, and all the real communication, if it exists at all, happens through side channels.
The ideal world lies somewhere in between.
Your project manager should not be too concerned with how you're doing things. Since they have no qualifications, the best they can do is connect you with someone who does. When they can't verify that you're building the thing right, they should at the very least ensure you're building the right thing. Even if it's for internal use, you still have a customer, and no communication with the customer spells bad news to me. :)
If your PM is not concerned about the issue, you could try to do something yourself. For example, ask the PM to connect you with a would-be end user of the application. Extract bits of your application and give them to the user to play with -- just make sure the bits you give them don't look or feel too finished.
If you can't change things, take this as a learning experience. Make sure next time you're up for a project, you know the things that went wrong last time, and try to mitigate them from the start.
And finally, if your bosses tell you this is a "more agile way" of working, punch them in the face. Agile is, or should be, synonymous with discipline, not complete lack thereof.
Good luck!
It is a hard situation. Only you can really determine the best way to proceed. However, I do think that the concern with the schedule and concurrent lack of documentation (requirements, expectations, use-case scenario documentation, etc) is a train-wreck waiting to happen. Even the sharpest and most experienced dev-teams suffer from the same problems.
The "when will it be done?" questions are best mitigated by regularly providing small partially functional builds that you can use to get useful information out of the moving target that is your customer. It is amazing how much communication can occur when somebody (your boss/customer/end-user) can actually "play with" something in front of them and reconsider what they really want.
I believe this situation is quite common. I had this, too, at my previous job. Here the bet is on the fact that you are already independent and well-versed in your business. I think you should tell your manager how you feel about this.
They should change something after hearing your opinion about this situation. Because if you do something wrong and the manager does not notice it, the company can lose a lot of money and time.
But it’s also not worth constantly waiting for someone to guide you and check your work. In any case, your workflow should have self-management.
Should developers be limited to certain applications for development use?
For most, the answer would be as long as the development team agrees it shouldn't matter.
For a company that is audited for security certifications, is there a method that balances the risk of the company and the flexibility, performance of the developers?
Scope
coding/development software
build system software
3rd party software included with distribution (libraries, utilities)
(Additional) Remaining software on workstation
Possible solutions
Create white-list of approved software where developer must ask for approval for desired software before he/she can use it. Approval would be based on business purpose/security risk.
Create black-list for software. Developers list all software used. Review board periodically goes over list.
Has anyone had to work at a company that restricted developer tools beyond the team setting? How did they handle the situation?
Edit
Cleaned up question. Attempted to make less argumentative.
Limiting the software that developers can use on their work machines is a fantastic idea. This way, all the developers will quit, and then the company won't have to spend as much money on salaries and equipment, resulting in higher profits.
Real answer: NO!!!
No, developers should not be limited in the software they use, because it prevents them from successfully doing their jobs. Think about how much you are paying your team of developers, - do you really want all that money to go spiraling down the drain because you've artificially prevented them from solving problems?
1) Company locks down the pc and treats the developer as competent as a secretary
What happens when the developer needs to do something with administrative permissions? EG: Register a COM object, restart IIS, or install the product they're building? You've just shut them down.
2) Create a white-list of approved software...
This is also impractical due to the sheer amount of software. As a .NET developer I regularly (at least once per week) use upwards of 50 distinct applications, and am constantly evaluating newer upgrades/alternatives for many of these applications. If everything must go through a whitelist, your "approval" staff are going to be utterly swamped by just one or 2 developers, let alone a team of them.
If you take either of these actions, you'll achieve the following:
You'll burn giant piles of time and money as the developers sit on their thumbs waiting for your approval team, or doing things the long slow tedious way because they weren't allowed to install a helpful tool
You'll make yourself the enemy of the development department (not good if you want your devs to actually do what you ask them to do)
You'll depress team morale substantially. Nobody enjoys feeling like they're locked in a cage, and every time they think "This would be finished 5 hours ago if only I could install grep", they'll be unhappy.
A more acceptable answer is to create a blacklist for "problem" software (and websites) such as Pidgin, MSN messenger, etc if you have problems with developers slacking off. Some developers will also rail against this, but many will be OK with it, provided you are sensible in what you blacklist and don't go overboard.
I think developers should have total control on applications that they use as long as they can do their job with them. Developers' productivity is directly related to working environment and no one will like being restricted and everyone likes to use software they like themselves.
Of course there should be some standards in terms of version control, document format, etc., but generally developers should have right to use any programs they want.
And security should be developer's concern - company admins should care about setting up proper firewall to protect against any kinds of attacks.
A better solution would to create a secure independent environment for the developers. An environment that if compromised won't put the rest of the company at risk.
The very nature of the development is to create crafty ingenuous pithy solutions. To achieve this, failures must happen.
Whatever they do, don't take away the Internet in general. Google = Coding Help 101 :)
Or maybe just leave www.stackoverflow.com allowed haha.
I'd say this depends on quite a list of factors.
One is team size. If you have a team of half a dozen developers, this can be negotiated whenever a need for some application pops up. If you have a team of 100 developers, some policy is probably in order.
Another factor is what those developers do. If they compile C code using a proprietary compiler for an embedded platform, things are very different from a team producing distributed web or PC software in a constantly shifting environment.
The software you produce and the target customers are important, too. If you're porting the Linux kernel to some new platform, whether code leaks probably doesn't matter all that bad. OTOH, there are a lot of cases where this is very different.
There are more factors, but in the end it all boils down to two conflicting goals:
You want to give your developers as much freedom as possible, because that stimulates their creativity.
You want to restrict them as much as possible, as this reduces risks. (I'm talking of security risks as well as the risk to ship non-functioning software etc.)
You'll have to find a middle ground that doesn't hurt creativity while allowing enough guarantees to not to hurt the company.
Of course! If you want a repeatable build process, you don't want it contaminated by whatever random bit of junk a programmer happens to use as a tool to generate part of the code. Since whatever application you are building lasts much longer than anyone expects, you also want to ensure that the tools you use to build it are available for roughly the same duration; random tools from the internet don't provide any such gaurantee.
Your team should say "The following tools are allowed for build steps and nothing else" and attempt to make that list short.
Obviously, it shouldn't matter what a programmer looks at to decide what to do, so the entire Internet is just fine as long as its just-look. Nor does it matter if he produces code by magic (or random tool) as long as your team doesn't mind accepting just that tool's output as though it were written by hand.
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 8 years ago.
Improve this question
I have begun work on a personal project that may end up having some real-world applicability. I am beginning to entertain the idea of selling licenses. I am sure some others here have done this before, and I was wondering what successfully processes you've used to do so.
There are many questions on SO regarding licensing, legal implications, etc. However, I have looked around and could not find a duplicate question for this one. To be clear, I am not looking for information on what licensing strategy to use, how to advertise your software, and so forth, but rather, for a checklist of things that should be done to increase the probability of success, and any possible gotchas I have not thought of. If anyone has any personal success stories, they would be very welcome.
For a little background, I am set on the idea of licensing a closed-source, compiled .NET DLL.
A few things off the top of my head:
Strong documentation, because formal technical support is unlikely
Specifying licensing terms and formalizing them with an attorney
Code obfuscation
Exploring license enforcement (either using a commercial package or custom code)
Building a website around the product, including real-world code examples since this is a library
Possibly offering some type of beta period, for feedback and getting the name out a bit
Offering instant/automated purchases
Marketing (oh boy)
Is it necessary (or wise) to start a one-man company to do this?
I will keep this list updated as answers come in. Thanks all!
Some tips:
Obfuscation: Be wary of obfuscating everything. An alternative is to obfuscate just the critical bits (licensing, premium features). The problem with obfuscating everything is that stack traces from error reports are ineffective. When an unexpected exception is caught, you'll want to give the user the option of automatically reporting its details - this really helps with QC.
License enforcement: If it's a utility that can be easily pirated, people WILL pirate it. An activations-based licensing system is ideal - and if it's not too draconian people will be less motivated to circumvent it. For instance, allow at least 3 activations per user (home computer, work computer, laptop). If it's a control library, then an activation-based may not be required - baking the serial number into the library may be enough because customers are unlikely to build their own product on a stolen assembly.
Instant/automated purchases: writing a custom licensing server and web page for this is fairly easy - you need only about 3 tables. LINQ to SQL is ideal for this sort of thing. For the payment gateway, I use PayPal - it's very easy to set up, has the features you need for selling activation codes, and allows multiple currencies. If you use PayPal, enable both PDT and IPN so you can give customers their activation codes both on the screen and via e-mail.
Marketing: try LOTS of things simultaneously - because it's hard to predict the success of any campaign. Especially without experience! Making yourself known amongst the influential people in the field into which you're selling can work very well.
Advertising: advertise on StackOverflow - that's what I'm doing! Google ad words is also worth trying because it's so cheap to set up - you'll know after spending $10 whether it will be effective for you or not.
And good luck with it!
You have most of the practical things listed out, in terms of actually getting a product from you to the customer -
However, there are a couple of things I'd also recommend.
Figure out how you want to handle all of your accounting/purchasing/billing/etc.
Rethink formal technical support (for money), but not at the exclusion of documentation
Talk to a lawyer regarding all of your licensing decisions, agreements, etc., as well as company structure
Talk to your accountant (and/or find one who is good at working with small tech companies)
Some of this will cost some money up front, but save headaches later.
The last two bullets are crutial - there are MANY options for how to setup yourself from a tax perspective, each of which has potential advantages and disadvantages depending on your specific situation.
For example, if you're in the US, there are many advantages to incorporation prior to doing anything on your checklist. If you decide to incorporate, you may want to do it in your state, but there are also advantages to incorporating in Nevada or New Jersey (very pro-corporate states legally). If you're successful, doing this early can save a huge amount of work over time and have significant benefits.
Also, if you incorportate, you might want to consider S vs C corps (S Corps are great if you're a one or two man operation). If you don't incorporate, you can run as a sole proprietorship or an LLC, both of which have advnatages and disadvantages. A lot of this depends on your product (what it does), your expected returns, etc. - having a good lawyer and a good accountant is a huge blessing.
If you're aiming at software development teams as customers then the sort of thing they are likely to expect to see (in addition to the ones you listed) are:
A download service for any additional items and/or patches that the user might need.
Tight version control/configuration management processes so that it's easy to find out what version of the product they have, what they need and what the differences are between versions.
Email/online bug reporting.
A demo/trial version of the product.
A good set of tutorials.
Community support e.g. developer forums. This is a good 'value added' service that can also help with the fact that you have concerns (as a one man company) over being able to provide 'formal technical support'. Hand out a few badges and reputation scores and get a free technical support team ;) ... but if sales take off, seriously consider providing 'formal technical support', it can make a huge difference to the perception of the product.
... and make sure that the website, download service, license server, forums etc are all properly secured and done to a professional standard. If any of the peripheral services are less than 100% then it all reflects badly on the product, especially when yours is a technical one.
You might not want to provide formal technical support, but you could look for creative alternatives like some sort of moderated forum for issue resolution. Also, provide at least an email address for someone to contact you.
Another thing is to hire some sort of designer to make your product, documentation, website, etc look good. It is generally easy to tell programmers who attempt design.