Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
The community reviewed whether to reopen this question last month and left it closed:
Original close reason(s) were not resolved
Improve this question
A friend of mine asked me the other day if I'm just looking at lists of numbers when I'm programming, or how it works. I tried to explain that it's generally more like math formulae, with the odd english word tossed in, and that it's generally mostly readable. But that's a very vague explanation, and it doesn't really explain much to a non-programmer.
But it got me to thinking about what would make a good example. Not because I want to teach her programming or anything, but simply to give her an idea of what program code "looks like".
And that got me to wonder about what would actually work as a good example. And that's turning out to be surprisingly difficult.
My first thought was obviously a simple "Hello World" program. But it really doesn't show anything useful. It doesn't really show how we use functions, or variables, or control flow structures like if or while to make a program that actually does something. There's no logic to it. The program doesn't react to anything.
So perhaps something like computing prime numbers would be a better example. But then again, that might be too theoretical and impractical... (What good is that? What does it have to do with writing "real" programs?) And again, there's no significant control flow logic in it. It's just a straight sequence of maths.
And also, which language should be used?
Ideally, I don't think it has to be a very "clean" language. But rather, it should probably make the structure clear. If it does that, then a certain amount of noise and clutter might be fine. Perhaps something like C++ would actually be a better example than Python for that reason. The explicit curly braces and type specifiers are obvious "hooks" to help explain how the program is structured, or to highlight that it's not just simple statements that can almost be read out as english.
But with C++ we also get into some downright weird syntax. Why is std::cout << x used to print out x? Why not a "normal" function call syntax? And printf isn't much better, with its arcane format string, and lack of extensibility (do I want to complicate the program by using char* for strings? Or do I use std::string and settle for calling the seemingly unnecessary s.c_str() to get a string that can be printed with printf?
Perhaps a higher level language would be better after all. But which one? And why?
I know there are plenty of similar questions here about which language/example program to use to teach programming. But I think the requirements here are different. When teaching programming, we want simplicity more than anything. We want to avoid anything that hasn't been taught yet. We want to make sure that the student can understand everything on the screen.
I'm not interested in simplicity per se. But rather in giving an "outsider" an idea of "what a program looks like". And programs aren't simple. But they do generally exhibit a certain structure and method to the madness. What language/program would best highlight that?
Edit
Thanks for all the suggestions so far. Some of you have had a somewhat different angle on it than I'd intended.
Perhaps an example is in order. I can't fly an airplane, but I've got a basic understanding of what the cockpit looks like, and what a pilot "does" while flying.
And I'm not a trained carpenter, but I know a saw or a hammer when I see one.
But when you see anything to do with programming in movies, for example, it's usually just screens filled with garbage (as in the green text in the Matrix). It doesn't look like something a normal human being can actually do. There's nothing recognizable in it. Someone who isn't a programmer simply thinks it's black magic.
I don't want to teach her to fly, or to program software.
But I'd like to give her a basic frame of reference. Just an idea of "ah, so that's what you're working with. So it's not just random symbols and numbers on the screen". Even just showing a simple if-statement would be a revelation compared to the Matrix-style random symbols and numbers.
Some of you have suggested explaining an algorithm, or using pseudocode, but that's what I want to avoid. I'd like something that simply shows what actual code looks like, in the same way that you don't have to be a carpenter to look at a saw and get a basic idea of what it is and how it works.
When I was a kid, we once went on vacation in Italy. On the way down, the pilot let me into the cockpit of the plane. Of course, I didn't learn how to fly the plane. But I did get a peek into the pilot's world. I got an idea of how they make the plane go, what the pilot actually does.
That's really all I want to do. My friend has no interest in learning programming, and I don't want to force her to understand source code. But she was curious about what kind of tools or entities I work with. Is it Matrix-style symbols scrolling across the screen? Pure mathematics? English in prose form?
All I'm interested in conveying is that very high-level understanding of "What does it look like when I work".
BASIC
10 PRINT "Sara is the best"
20 GOTO 10
Update: when I was 12, my cousin (he was 14) brought Turbo Pascal 7.0 and installed it in my computer.
He programmed a tic tac toe game from scratch (in BGI mode, for those who know).
I watched/observed step by step how a program evolves until it becomes a complete application.
Until then, I knew only how to print strings in BASIC :-B
You can do a similar thing. Pair programming. Well, actually your friend will be an observer but she'll get an idea ;)
Why not consider a language that doesn't exist (or does, if you so believe) and use Pseudo Code? I think, depending upon what you want to achieve - I'd consider the example of task familiar to the person, but carved up into a pseudo code example.
I generally find the idea of "cooking" or "recipes" to be a great fit when explaining things to non-programmers.
I ask the person to imagine they had a recipe that was fairly complex - e.g. a curry & rice dish. I then suggest that they should try and write it down for someone who has absolutely no idea what they are doing, so that they can cook it.
There is a very definite few stages involved:
Gather the ingredients and tools for the job.
Prepare the ingredients. This is complex. e.g.
get 3 Small Red Peppers.
for each red pepper you have, chop it into chunks about 1cm square.
place the red pepper chunks into a bowl for later.
Seperately to this, call the prepare rice function and have this working asynchronously in the background while you continue on with the cooking.
I'm sure you can see where this is going... ;)
There are a lot of similarities with Cooking and Programming (as there are with many things, but more people have an understanding of cooking than of building a house).
There stages / similarities (as I see it) are:
Gathering: (declaration of what is required to achieve the goal and getting them together).
Preperation: Chopping the ingredients or readying the data connection objects etc for first use.
Asynchronous: The ability to have one thing going while another thing going.
Functions: The rice making, the chicken cooking and the curry cooking all require separate processes and only at the end can you have the makeCurry(chickenMeat, rice) function.
Testing: Ensure that as you are going along, you aren't missing any bits and that everything is going smoothly - e.g. ensuring chicken is cooked before you move to the next stage.
Garbage: Once you've done, you must ensure that you tidy up. ;)
Principals of Best Practice: There are efficient ways of doing things that like cooking, beginning programmers have to learn in addition to the code - sometimes it can be hard to get your head around. e.g. D.R.Y, how to chop efficiently with a knife & don't eat raw chicken ;)
Basically, I think for teaching programming as a general topic - I wouldn't necessarily teach from a language unless you had a compelling reason to do so. Instead, teach initially from the abstract until they understand at least the fundamentals of how things might fall together. Then they may find it easier when sat in front of a monitor and keyboard.
I think there may not be one "right answer" for this one. But I think maybe a few really good ideas you could maybe take bits from all of.
I would explain that programming is giving detailed instructions so the computer can make complex tasks.
How to make two cups of coffee?
Fill the kettle
Boil water
Coffee in cup
Pour on water
Add sugar
Add milk
Do 3 to 6 again
To answer your question directly - what programming “looks like”, I'd show them a print out of a large application. Toy apps or cute things like qsort in haskell really give the wrong idea.
It looks a bit like this. Sometimes.
Maybe everyone is concentrating too much on the code rather than tools. Possibly it's best to show her a project in an IDE, and how it includes various source files and maybe some diagrammatic things like a database schema or a visual user interface designer too. Visual Studio, Eclipse or Xcode are quite far away from most people's mental image of rapidly scrolling glowing green symbols on a black background.
I think you should download some big win32 application, written in AT&T assembly language, and show it to her in notepad, and tell her, "As you can see, it takes a superhuman like myself to program."
Code something that has any comprehensible value to a non-programmer. If I'd demonstrate Quicksort to my mother, it wouldn't be of any use.
Ask the person about his interests. If he/she's into stock exchange for example, hack together a script that reads some stock statistics from a appropriate web page and compiles them into an excel sheet (use csv, to avoid heavy brain-damage ^^) or maybe into a nice graph.
If the person uses Twitter, code something that counts the followers of his followers or something like that.
These tasks are simple enough to be done in a very short time and they already utilize a lot of the basic tools that we programmers use, like loops, libraries (for all the http stuff involved), maybe recursion.
After you're finished or while you're coding (even better), you can explain how your program does its magic.
Just keep it simple and talk in human language. If you show them megabytes of code and talk about things like prototypal inheritance, you just intimidate them and they will lose interest immediately.
To give my wife an idea of what I do to bring in a paycheck (It's real work! I promise! we don't just browse the web all day!) I sat down with her one evening with Python and showed her a couple of the basic concepts: calling a function (print), assigning and reading a variable, and how an if statement works. Since she's a teacher, I likened the concept of conditionals to working with preschoolers :)
IF you hit Jonny THEN you're in time out OTHERWISE you can have a snack.
After reviewing a couple of the very high level concepts, I then showed her the code to a simple number guessing game and let her play it while looking though the code.
# Guessing Game
import random
print("Guess a number between 1 and 100: ")
target = random.randint(1, 100)
guess = 0
guess_count = 1
while guess != target:
guess_count += 1
guess = int(input())
if guess == target:
print("Correct!")
if guess < target:
print("Higher...")
if guess > target:
print("Lower...")
print("Congratulations! You guessed the number in " + str(guess_count) + " guesses!")
Aside from the somewhat abstract concept of "import", this is a very straightforward example that is easy to follow and "connect" to what's happening on the screen, not to mention it actually does something interesting and interactive. I think my wife walked away from the experience a little less mystified by the whole concept without really needing to know much in the way of code.
I think the key is being able to have someone see the code AND it's end result side by side.
There was a CLI graphics package called LOGO, and best known for Turtle Graphics, used to draw shapes on screen using commands like LT 90, RT 105 etc. See if you can find that, it would be a nice experience to try and draw something of medium complexity.
LOGO - Logic Oriented Graphic Oriented programming language.
REPEAT 360 [FD 1 RT 1] -- draws a circle, etc.
See more at logothings or Wikipedia which also has links to modern logo interpreters.
The computer programmer writes programs.
While not programming, the computer programmer annoys attractive women in his workplace.
Then:
(source: markharrison.net)
Now:
When my 5 y.o. daughter asked me the question I made her "develop" the program for a little arrow "robot" that will get him into the upper-left-corner of the board using flowchart-like pieces of paper signifying moves, turns and conditions. I think it applies to grown-ups as well.
I do not claim the invention of this answer, though.
About your edit: I'm afraid, programmers have even less idea of the idea others have about programming. ;-) People think that programming is a matrix-like green video card corruption about as much as they think that spies are all equipped with James Bond's hi tech toys. And any professional in any field is normally irritated when watching the movie concerning his job. Because the movie maker has no idea! Do we know how to properly depict programming in the movie on the other hand? ;-)
I've found that the best approach to "teach someone what programming is without teaching them programming" is actually to just drop anything related to a specific programming language.
Instead (assuming they're actually interested), I would talk them through implementing a function in a program, like a simple bank loan application (most people have had to deal with loans at some stage, if they're above a certain age), and then poking holes in all the assumptions.
Like, what should happen if the user types in a negative loan amount? What if the user cannot afford the loan? How would the loan application know that? How would the loan application know which bank account to check and which payment history to check (ie. who is the user actually)? What if the user tries to type in his name in the loan amount field? What if the user tries to take the loan over 75 years? Should we limit the choices to a list of available lengths?
And then in the end: Programming is taking all of those rules, and writing them in a language that the computer understands, so that it follows those rules to the letter. At this point, if it is felt necessary, I would pull out some simple code so that the overall language can be looked at, and then perhaps written out one of the rules in that language.
Bonus points if you can get your friend to then react with: But what if we forgot something? Well, then we have bugs, and now you know why no software program is bugfree too :)
Definitively something either with graphics, or windows, in a higher level language.
Why? A non-programmer is usually a non-matematician too, that's why he won't get the beauty of sorting. However showing something drawn on a screen ("look, a window!", "look, so little typing and we have a 3D box rotating!") can work wonders ;).
What does it look like when you work?
It looks like typing.
Seriously though, programming is kind of like if Legos were text, and to build a big Lego house, you had to type a lot of text in, just right, hooking up the right pegs with the right holes. So that is how I generally describe it.
It's really hard to understand what programming is like just from a source code example, because it is so abstract.
There is nothing wrong with starting on hello world, as long as you can show what the computer actually does with it. You can then introduce one construct at a time. That's what programming is like- Making incremental changes, and seeing the results.
So you have a hello world program. Now change it to
string Name = getLine();
printf("Hello, %s", name);
then the if construct
printf("Do you like cake?");
string answer = getLine();
if(answer == "yes") {
printf("Yeay! I like cake too!");
} else if(answer == "no") {
printf("Filthy cake hating pig!");
}
then demonstrate that the last program fails when it recieves an answer other than either "yes" or "no", and how you would go about fixing it....
and so on. I don't think you need to go into deep concepts like recursion, or even functions really.
It doesn't really matter what programming you use for this, as long as you're able to show, on a computer, the result of these different programs. (though these psuedocode examples are probably pretty close to being valid python)
Robotics is great for explaining programming, I think, because even simple, contrived examples are practical. The robotics equivalent of Hello World or printing a list of numbers might be having the robot move in a line or spin in a circle. It's easy for a non-programmer to understand that for a robot to do ANYTHING useful it must first move and position itself. This lets you explain simple program structure and flow control.
You want the robot to move forward, but only while there is nothing blocking its path. Then you want it to turn and move again. That's a simple routine using basic flow control, and the functions that you're calling are pretty easy to understand (if your platform has decent abstractions anyway).
Graphics might also work. Anything that has immediate results. jQuery even, because everyone is familiar with rotating pictures and web animations. Even contrived examples like pushing elements around in the DOM has an easy to see effect, and most people will understand what and why the statements in the program do.
Things like Robocode and LOGO are probably really good for this.
(source: wikimedia.org)
{
wait for 6/8;
play F (5), sustain it for 1/4 and a half;
play E flat (5), sustain it for 1/8;
play D flat (5), sustain it for 1/8 and a half;
play F (4), sustain it for 1/16;
// ...
}
Perhaps a metaphor could be that of a composer writing a musical score. The job of a composer is the intellectual activity of creating music. With a score, the composer is telling the pianist what to play, and he does it by means of precise instructions (notes, pauses and so on). If the "instructions" are not precise enough, the pianist will play something different.
The job of a software developer is the intellectual activity of solving problems (problems that have to do with automated processing of data). With source code, the developer is telling the computer what to do, and he does it by means of precise instructions. If the instructions are not precise enough, the computer will do something different and will not solve the problem correctly.
I would just write something in pseudocode that demonstrates how to use a computer to solve an everyday problem. Perhaps determining which store is cheaper to buy a particular grocery list from or some such.
Why not just show the timelapse video A Day in the Life of a Scrum Team?
A programmer writes instructions for the computer to perform.
Running the program results in the computer actually following those instructions.
An example is a cook will follow a recipe in order to bake a loaf of bread. (even if it's in their head)... that's programming. Unlike my wife, the computer follows the recipe exactly every time. My wife, does it in her head and it turns out different but delicious every time ;-)
If you want to go ahead and teach this in more detail then pseudo-code is easy to understand.
e.g.
IF today's date is the 1st of may then
print to screen "Happy Birthday"
ELSE
print to screen "It's not your birthday yet"
The beauty of psuedo code is nearly anyone can understand it and this is the point of it.
Want to show her what programming looks like? Just pop a terminal and
find /
Surprised this is still open, and surprised no one has already given this answer. (I think. I might have accidentally skipped one of the 40 questions that no one is going to read anyway.)
Your answer is in your question
When I was a kid, we once went on vacation in Italy. On the way down,
the pilot let me into the cockpit of the plane. Of course, I didn't
learn how to fly the plane. But I did get a peek into the pilot's
world. I got an idea of how they make the plane go, what the pilot
actually does.
That's really all I want to do.
That's all you have to do. Pick a short exercise out of a tutorial. A moderately longer GUI one could also be beneficial due to the added visuals. (Games might be pushing the length a bit.) And let her watch you code. That's it. It's the same as your pilot example.
Also there are a number of online REPLs that will make watching you code even more immediate.
I say show him bubble sort.
It's an easy, understandable trick, converted to a formal language.
That's what our job is about. Expressing our ideas in a strict, formal language, such that even a machine can understand. A little similar to designing procedures for organizational design.
Code up something quick that reads stock quotes and writes them to an excel spreadsheet. This is easy enough to do with a few minutes and impresses non technical types very quickly as they see the practical value of it.
My usual choice is to retrieve a set of customer records from a database. Using C# and LINQ in Visual Studio, it takes maybe 10 minutes at most to build a web page and dump out the "Northwind" database customers into a grid. The nice thing is that a "list of customers" is something that almost anybody can understand.
Totally depends on the level of her interest (or your level of interest in her). Most people ask that question as idle conversation, and don't really want to know.
Programming is more than algorithms (like "How to make a cup of coffee), it's also fundamentally rooted in mathematics. Most people will be quickly tripped up by the subtle use of mathematical terms (what's a "function"?).
In order to really teach programming, it may help to think back to your own first programming experiences, your first programming teacher, your first programming language. How did you learn? when you were learning, what skills did you already have fresh in your mind (i.e., calculus)? What motivated you to want to understand what a variable is or why there are three different kinds of loops?
Language-wise: Use something like python. Really high level, non-curly-bracket probably better.
Alice which was developed at Carnegie Mellon.
Alice is an innovative 3D programming environment that makes it easy to create an animation for telling a story, playing an interactive game, or a video to share on the web. Alice is a teaching tool for introductory computing. It uses 3D graphics and a drag-and-drop interface to facilitate a more engaging, less frustrating first programming experience.
In pseudo-code:
function dealWithPerson(person){
if(ILike(person)){
getCookie().giveTo(person);
}
else{
person.tell("You shall receive no cookies!");
}
}
dealWithPerson(Person.fromName("Nick"));
dealWithPerson(Person.fromName("John"));
This demonstrates the concept of functions, object-orientation and strings, in a C-like syntax(when I say C-like syntax I refer to the weird characters).
It also shows how code can be reused.
Note that although it is pseudo-code, I wouldn't be surprised if there was some language that accepted this syntax(perhaps JavaScript allows this?).
You could also adapt this example to have loops.
Hope this helps show that person how a program looks like(since it is a realistic syntax and it is relatively easy to understand).
I have been teaching programming for many years and found out that the number of ways you need to explain things is equal to the number of students you have. But one method that works most of the time is as follows:
Present a flow chart that shown the flow of logic of a simple application
Write the instructions in full human language (e.g. English)
Abbreviate each instruction to the short-hand used in the programming language
Choose a less cryptic language like Basic or Pascal for teaching purposes
All code is simply shorthand for natural language. Written in full English most programs seem trivial.
As for a good algorithm, that is another story. It is sad to see many Computer Science courses no longer teach algorithms or brush over it.
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.
Just want to ask for some opinions here. How do you feel about using a language (and/or framework) that isn't widely used in your location to write software for a company? For instance, I live in an area dominated by .NET, with the occasional PHP job. Let's say that I'm learning Python and decide to use it to write software for my job (I'm a "Team of One" so I can pretty much use anything I want).
Now their software is written in a language that pretty much nobody in the area uses or knows; if I were to leave the company, they'd basically have nobody to maintain/add to it unless they retain on me as a consultant. While that's really good for me, it seems a bit "crooked" - granted, that's how the business world works.
What are your thoughts?
I should mention that this is a very small company and I'm the only IT person, so I have full reign to choose our development platform. I'm not specifically using Python, but chose it as an example since my area is almost entirely .NET based; I don't care for .NET anymore though, which is why I don't want to consider using it. Also, the company is.. how shall we say... extremely frugal and wouldn't purchase the required resources for .NET (e.g. server licenses, SQL licenses, Visual Studio, components). I personally have an MSDN subscription but I can't use that for them.
Also FWIW there are people in the area who use the language I'm considering using (Ruby on Rails), but nowhere near as many people as .NET developers. It's not like I'm using something that only I know.
You may think that this approach is good for you. But in fact all this does is paint you in to a corner. The best way to get promotion - within an organisation is to make yourself unnecessary in your current position. That might seem like nonsense, but it is in fact true. Think of it like this, if it is essential to the company that you continue to maintain the python code you wrote for them, and they can't go to anyone else to get that skill, then they will continue to pay (maybe a little above market rates) to maintain that code.
If however, you write that code in .net where there is a plentiful supply in your area, then as the company expands and the code you've written proves successful, you will be able to hire people to maintain that code and you can move on to designing other systems. Or moving in to managing a team of .net coders - if that's your want.
Even if you want to leave, the best thing for your career is going to be to get the best possible reference. To do that, write them some code that is easy to maintain. Help them hire someone to replace you to maintain it. They will be grateful and recommend you as a consultant to their friends.
Code in something esoteric - for which there is little support in your area - and they will be saying to their friends on the golf course "no don't hire that guy, he wrote this system for us which does the job, but no one else can maintain it. We're stuck with him forever and now he's too busy to look after us properly!"
Do what's best for the business, not what might be of most interest to you - or appear that way on the face of it. You'll win out in the long run.
I think that you're responsible to decide on the language that's best suited for the job. That includes an objective evaluation of the merits of the language and framework, it includes your own personal skill with the language (since you're the one doing the work) and it includes maintainability by others. Only you and your company can decide how much importance to place on each of those.
For your own personal development, if your area is dominated by .net, why don't you want to get up to speed in that instead of Python?
From an ethical standpoint, I would not write something that could not easily be maintained by someone else.
A lot of responses seem to be a poor fit for the question. We're not talking about using an unapproved language in an environment with existing standards. We're talking about a situation where the poster is the entire IT and development department for his company.
It's certainly important to keep in mind availability of talent, but Ruby is hardly a fringe language these days. In an environment where there's only one developer, productivity is also a very important consideration. Being able to build and maintain software quickly and easily without a large team requires tools with different characteristics than a large team might require.
I think what's more important than whether to use Ruby or (something else) is to try to pick something as general-purpose as practical and use it for everything unless there's a really good reason to use something else. If you go with Ruby, stick with Ruby for your utility scripts, cron jobs and that little GUI app the boss wanted to automatically SMS the intern when he takes more than five minutes to bring him his coffee.
I think using python would be the right thing to do if it would meet the clients requirements, and save them money over the alternative. Whether or not there is a wide assortment of characters to work on the application down the road is irrelevant, unless they've specified this as a non-functional requirement.
As usual, using the best tool for the job at hand will serve you well.
It indeed is a bit crooked IF you use it only for that purpose.
However, if you use it because it IS the best solution, youre in the clear.
Also, they can just hire someone else who knows python.
My work ethics dont allow me to do something like this just to keep me in business.
My personal opinion is you should try where possible to respect the working practices of wherever you are - whether that's indentation style, naming convention, testing procedure or programming language.
If you feel strongly that a different language would be better suited for a certain task, then lobby to have it accepted (with the required re-training of others).
Purposefully leaving an app that no one else can maintain is very bad professional conduct, IMO.
We recently had a bad hire at my shop and he decided out of the blue he was going to use Perl instead of any version of .NET to do some simple reporting stuff (That could have just as easily been done in .NET). It was atrocious. I would suggest using the platform as specified and clearing any deviation with the people who run the joint...
Plenty of answers have touched on this, but here's my take based on production application support.
My company had a startup phase where code hustlers whipped up solutions in whatever the personal preference or flavor of the week was. Bad for maintainability and supportability.
Making a change is ok, though, as long as it's consistent. If Python is going to pave the way to the future, then go for it. Don't forget that the legacy .NET and PHP code still needs to be supported until end of life. Building yourself a hodge podge of platforms and frameworks will just create more difficulty for you on the job and the company when you're no longer around.
If you feel in your heart you are acting dishonestly, then you probably are.
No one likes a dishonest person. That can't be good for your reputation.
Do your best to choose based on what is actually best, not what satisfies some underhanded motives.
It depends. I did some of what would normally just be a bash script, in Java instead at one place. Why? Because they're all Java programmers and frequently have interns/coops coming through that may or may not know anything else (and may or may not even be all that great with Java).
Other places though tend to have more experienced programmers and I expect that they'll be able to figure out another language without too much effort. So, I would go with what's "best" for the project.
I agree with what mquander says above, but you may also have to be prepared to justify why you want to use this other language to your development manager. If he/she then agrees, perhaps the language could become more widely adopted within the company.
Think of it in terms of business benefit you bring to the company, now and in the mid-term.
If you can deliver something much faster using a different technology, and it still achieves the goals, I'd go for it - but I'd still let some other people know and respect the company's final decision. If however, it's purely for yourself, then I'd probably be a litte more careful.
I think it's a really bad idea. For you, it means there's no back up in case you want to have a day (or week) off. For them, there's no one else if you leave or are taking a day off. It's a well known ploy, and, honestly, might be reason to not keep you around.
However, this could also be a chance to introduce Python into the environment. You could teach others about it, and explain to management while it's a good third language to have at the group's disposal.
I used to think that you should always pick the right language for the job at work. I'm reversing my opinion though.
The problem arises when some other guy picks a language you don't want to learn. I am concerned that I might be the guy who picks the language no one else wants to learn. Just because I think that Erlang might be the right choice for something doesn't mean that everyone else will want to learn Erlang or respect my decision for using Erlang.
"if I were to leave the company, they'd basically have nobody to maintain/add to it unless they retain on me as a consultant."
Are you saying no one else can learn Python? I find that hard to believe.
New technology is often introduced in small projects by knowledgeable people and diffused through the organization because the small projects were successful.
Use Python. Be successful. Make your case based on your successes.
I had this same problem very often. Coincidentally, it was with those two languages you mention: .NET forced on me, when I preferred to use Python (among others). Could be the opposite, I don't judge.
I refrained to use Python, because of the reasons already mentioned in other answers. I did what I thought was best for the company. Using IronPython won't make your python code any more maintainable for an unexperienced Python programmer.
However, I left the company and now I work in something more in line with my tastes. I'm much happier. In this economy you may not have this option... but it will pass. Do the right thing.
Cheers.
There is a large difference between 'prototype' or 'one-shot' code and production code. For prototyping I use whatever works fastest, but I'm very clear about its status. Production code is written in one of the approved and supported environments.
The ethics is to use the best tool for the job. If there is a tool that takes you only 20% of the time to code vs other choices, and next to no maintenance, and easy to re-factor, you have a duty to pick that tool, assuming it's extensible as you may need in the business.
If you do a good job, hiring future people and training them in terms of HOW your workplace does business should be the practice of any growing business. They will be able to learn the code if they're the right person for the business.
In your case I'm not sure if you want to use Python, unless it has native .NET support to allow your .NET world to interact with it.
Other posters have made some good points, but here's one I've not seen: Communicate the situation to management and let them decide. In other words, talk with your boss and tell him or her that there currently are more .NET developers in your area, so that if you're hit by a bus tomorrow it would easier to find someone else to maintain your code; however, there are tools you need to do your job more efficiently and they cost money (and tell them how much). Alternatively, you could do this in Python or RoR (or whatever) and use free tools, but from what you know, there aren't currently that many people in the area who know those languages. I've used "currently" a couple times here because this may change over time.
Before having this conversation, it might be good to see if you can find user groups for the alternative technology in your area, and how large they are. You could also ask on listserves if there are people who know the alternatives in your area.
Of course, the boss may tell you to keep using .NET without any tools, but in that case it's their decision to shoot themselves in the foot. (And yours to decide if you want to find a new job.)
Regarding the question as asked, I see nothing unethical about it, provided that:
It is a freely-available language. Although I am something of a FOSS partisan, that's not the point of this criterion. It needs to be freely-available (not necessarily FOSS) so that it doesn't impose costs on the company and so that others will have the opportunity to learn it if you ever need to be replaced (or if they want to compete with you for your job).
You are changing languages for solid reasons and not for the sake of creating vendor lock-in (or, if you prefer to think of it as such, "job security"). Ethics aside, you really don't want to have a job where they hate you, but are stuck with you because you're the only one who can maintain the mess you've created anyhow.
In the particular case you've described, I would suggest that switching to RoR may be the more ethical choice, as it would be decidedly unethical (not to mention illegal) to use .NET if there are required resources which are for-pay only and your employer is too cheap frugal to purchase proper licenses for them.
When in Rome... do as the Romans.
You might not be the one who as to maintain this code in the long term and not everyone wants to learn a "fringe language" to make bugfixes or enhancements.
I migrated some VBA stuff over to Perl for processing at a previous job and increased the efficiency by several orders of magnitude, but ultimately no-one else there was willing to learn Perl so I got stuck with that task longer than I wanted it.
I did that, it was Delphi in my case. I think Delphi was used often however when i was looking for a job .... i saw 3 delphi job offers in my whole life. i also saw more java/j2ee/php offers that i can remember. i think its bad idea, with the time i wasted in learning advance delphi programming i could get better with j2ee and start in better company and maybe make now more money.
If they cant find somebody to maintain the app you will always do it and when you quit they will have to re-write it. i think consultant thing is not used often.
I used to be in the "use the best tool for the job" school, but I've changed my mind. It's not enough to just ask "how can I do this job the fastest." If you think you're the only one who will ever need to look at some code, there's a good chance you're mistaken. The total cost of introducing a new language into an environment is higher than you might imagine at first.
If you just need to produce a result, not a program, then you can use whatever you want. Say you need a report or you need to munge some files. If the output is really all that matters, say it's something you could have chosen to do by hand, you can practice using any language you want.
With the release of the MVC Framework I too have been in a similar ethical delema. Use WebForms or switch over to MVC Framework for everything. The answer really is you have to do the right thing and use whatever the standard of the company is. If you deviate from the standard it creates a lot of problems for people.
Think how you would feel if you were dumped a project on VB6 when all you have been doing for years is .Net. So these are the two solutions I have come up with.
Use your fun languages for consulting contracts you do on the side. Make sure the client knows what you are doing and if they agree go for it.
Try and convince your current company to migrate over to this great new language you are working with.
If you follow these routes you will learn your language and not piss anyone off in the process.
Ruby on Rails is certainly not a fringe language. If the company is too cheap to pony up for the appropriate licensing for Microsoft's tools, then you would have no choice but to find an alternative. RoR certainly would be a reasonable choice and if helps move your career along as well, then it's win-win for both of you!
You can develop .NET adequately with free tools; cost is not a good reason to avoid that platform. Ruby on Rails is becoming reasonably mainstream for building data-driven internet websites. You haven't even told us if thats the sort of software you are building though.
There is really no way with the information that you have provided that anyone can give you a single correct answer.
If you are asking is it ethical to do your work in such a way that the company is dependent upon you, of course the answer is no. If you are asking is it ethical to develop in RoR then the answer is "we don't know" - but my opinion is that probably it would be fine if its the right tool for the job.
Don't underestimate the ability of someone else to support your work or replace you though - if you do your work reasonably well once the solution is in place any programmer worth their pay should be able to learn the platform well enough to maintain it. I've debugged, migrated and supported a few PHP applications for example without ever hardly learning the first thing about PHP. I'd be lost building a new PHP app from scratch and would never even try but its no problem to support one. I think the same would be true of the languages you mention as well - they've got the critical mass that means there is plenty of books and forums etc. Of course if its written badly enough in any language then it may be difficult to support regardless of anyone's skill in the language...
So much discussion for such a clear-cut situation...
It's not up to you, it's up to them. If they're not technical enough to make the call, as it seems, then you have to make it for them in good faith. Anything less is dishonest, and I'm fairly sure that's not in your job description ;)
You've muddied the waters with all the wandering about in the thickets of personal motivations. The answer to that one is that your personal motivations are irrelevant unless and until you've formulated the business case for the possible decisions. If you've done that and the answer still isn't clear-cut, then sure, choosing the answer you like the best is one of the nice things about being in a position to make technical decisions in the first place.
As far as the actual question goes, to my mind if the most technically apt choice is also one that very few people work with, one of two things is happening: a) It's a good choice, and the number of people working with it is going to be exploding over the next 18-24 months (e.g. Django), or b) There's something wrong with my analysis. Technologies may be on the fringe because people are slow to adopt them, but that's generally not why they stay on the fringe.
If you find yourself thinking "I can't choose technology X, that'll make it easier for them to replace me!" you're in the wrong line of work. In almost any enterprise that's not actually failing, the IT guy who makes himself easy to replace tends to move up to harder and more interesting and more lucrative work.
I would not bring a new language/framework/whatever into the place unless they understood that's what I was doing, and that if I left/was fired/was hit by a bus, they'd have to find/train someone to work with it.
I have some experience in a contractor pulling in things just because he felt like it. In some cases they were the best tool for the job (in other cases they were not), but in all cases they were not the best tool for the team that had to maintain the code. In my case the contractor was a serious jerk who didn't really give a darn about anyone else and I believe WAS trying to make himself harder to replace.
In your case, talk to your bosses. If they really don't want to spend the needed money on .NET framework tools/libs, then switching to something else may well BE the right thing to do for them, long term.
And, as someone who has spent his career walking into the middle projects that others have already started - thank you for thinking before you add a new tool to the mix.
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 dealing with an issue with my current employer that has seriously made me consider seeking employment elsewhere. They are under the impression that 100% of custom development should be eliminated and replaced with COTS products, such as SharePoint. While I realize that this is not a realistic expectation, I've found it impossible to argue my points with the people in management that share these views. Their argument usually involves something along the lines of a feature already existing in SharePoint that covers feature X, therefore there is less risk involved and testing doesn't have to be done against it.
Case in point, we have a situation where a SharePoint list is completely incapable of meeting customer expectations and requirements. Saving this data in a SQL database, however, would easily satisfy the requirements. Any time our development team suggests going outside of the boundaries of SharePoint, however, management goes up in flames about how every line of code adds to the complexity of the project and increases risk. While this is certainly true in some situations, it's not always the case. Their argument, however, is that since SharePoint provides a mechanism for storing data, that we should use it 100% of the time. Regardless of if it meets customer requirements, or not.
I've gotten to the point that I hate coming to work because I'm constantly forced into doing things that I know (with 100% certainty) are not right and that could be made right by doing custom development. It's simply what seems to be an impossible argument where I work, however.
Have any of you experienced a similar situation? If so, what have you done to work through these challenges?
If you don't share the vision of the company and if you can't enlighten them then sure, it is a good time to start looking.
Have you pointed out that there is risk in forcing a "solution" on a client that does not help them or is missing functionality or is unusable?
Perhaps come up with plans to address and mitigate their perceived risks.
You document your concerns and let those above you know them, and then you do as they ask. If it doesn't work, you have documentation that you brought the concerns up. But try to make it work their way, so it doesn't look like you're trying to undermine their plans. They're taking the greater risk, and thus they get the greater responsibility. Try your best to make it work their way, and quit worrying about it.
This may sound bad and may not be the answer you want. There is a little known division in my office called "The Skunk Works." People, on their own accord (usually during lunch breaks or compile time) decide to write little programs that help the company. The fun things about this is the result doesn't "cost" the company anything.
The conversation usually goes like this:
"We need to buy this software" -Boss
"But, we have had that thing for months. John, wrote that back in the day" -Programmer
"?" -Boss
A lot of times the developers see a decision as being bad and just create a parallel process that happens automatically. Then, when the stuff hits the fan and the customers are frustrated, the alternate solution is ALREADY in place.
I have an example of an auto release machine. Developers used to create these custom reports. As our customers increased, the developer's workload increased. The problem was "In order for the customer to get the custom report developer had to be involved." So, while the company was looking into hiring someone to do reports full time or to find ways to have the customers do them, I wrote an auto release machine that looks for report changes and releases them directly to the customer. I also wrote a utility that allows anybody to make changes to the reports that was easier to use than what the developer has. When the Boss made the announcement of trying to find a solution, I told him that it was already in place and that even he could make changes to reports and get them released. Now, everybody can change reports, usually it is management and customer support who make these changes. The fun side is that developers arn't involved anymore.
Just do it. If you're going to quit anyways, might as well try.
Does someone in management own stock in SharePoint? Was the system developed by the CEO's younger brother?
If they are that resilient to change, you should find out the real reason before trying to argue with them. They may claim that there is added complexity, difficulty testing, etc, but if you can counter every argument with one that shows their position, with all due respect, to be misinformed, and they still won't discuss, then you may be arguing the wrong point.
If they are locked into the technology because of a non-technical reason, such as someone once read that SharePoint is the ultimate in any technical situation (and, of course, had no clue what the article was talking about other than SharePoint = good) then you shouldn't bother trying to argue and save your energy. For the job hunt.
Prove it to them. When the requirements ask for a list that can handle 100,000 items with a multi-column sort - write a script that adds 100,000 test items into a sharepoint list and let them try it, preferrably with the "customer" requesting the list watching. :-)
I would definitely get my resume out and into the open if I were you. Not only is the experience that you are currently having frustrating, it can really hurt your career development over the long haul. Just think about it. While you are languishing with your current employer in your current position, other developers are adopting new technologies and expanding their experience.
There is such a thing as ideological differences between developers and what a company's idea of a role for a developer is. If open discussion and candor get you nowhere, you will not be faulted for a lack of effort. Loyalty to a company is a good thing, but the relationship needs to be a two-way street.
Sadly, the will eventually probably come to realize that they are wrong in their assumptions - but you can not wait for that day to come. Sometimes it never comes. In particular (and don't get me wrong, I love SharePoint when it is used for what it is intended for), SharePoint is become the next Access, in that people who read management magazines see enough of it thrown around to call it the messiah.
I find that there is typically no way of 'winning' these debates through talk alone. Many managers form an opinion of a product or solution through reading management oriented articles. See if you can find some counter-articles.
If you can cite examples of things which SharePoint is incapable of doing, and show examples of how you can cost effectively solve these problems through custom development then you are well on your way.
The mistake is to try and make this a conversation about technology, it's not, its about efficiency, cost effectiveness and maintainability - those are the mantras and metrics which will sway non-technical managers into considering alternatives.
If you can put together a proof of concept for some of these issues so much the better, eye candy really helps to sell outside of technical teams.
Finally, good luck :)
I am doing the same thing at my current job, there is no easy way to deal with this kind of situation. All I have been able to do is swallow my arguments, cause they have gotten me no where, and do as required by my management. This off course will go against your basic programmer nature of using the best solution for the task at hand, and maybe getting to build something cool in the process, but since they are the boss it is really your only solution. You could try to site cases, with evidence, where it makes more sense to use custom solutions. But if you boss is anything like mine, it won't get very far before the screaming match begins. The only other solution is dusting off that resume and finding a new job.
I have faced the same kind of challenges right from day one. Management have a natural reluctance to add custom code to the solution. However in most cases it has been posible to explain than the right solution for the customer would include some custom code.
Remember, if you argue that you can include the custom code in the common codebase, then the boss might approve the idea.
I really feel your pain.
If it was me I would use my spare time to collect information that proves my point and document it in a easy to understand way.
If they only understand money, talk money, if they only understand fear (doing "this" because they are scared of "that"), use the fear, finding scary thing for them in "their" solution.
Document every new implementation, the time, money and problem that arises. And document what your solution would be instead.
They probably doesn't see the problem in their solution, because they focus on not having problems in "your" solution.
I have worked in a place where management were not constructive in their approach, not quite as bad as you describe, but bad enough.
There are a couple of options. One is to go ahead and do what needs to be done for the client with the best "value for money" option you can. You will probably have to get the developers together as a team to make this "civil disobedience" work.
A more forceful approach that will really make the shit hit the fan is to go to the client (don't do this if it is an external client or if you wish to keep your job) and lay out what is going to happen to this project if X and Y. This is pretty much telling tales out of school and is going to be bad, but entertaining.
A slightly better way is to go up the chain and get a sponsor who can make shit happen for you. Essentially go behind your boss(es) back. This may work, but it is going to have predictable results for your relationship with your management.
Last and hardest is to identify the person who holds the view that any custom code is bad and engage them in conversation to find out where they got the belief and counter that with examples. Emphasis on conversation as you will have to listen to and understand their underlying concerns (which won't be about custom code per se) and only address them after you gain that persons trust.
I cannot tell you which way of doing things is going to work best because it depends so much on the individuals involved. All I do know is that you cannot change people and in my experience the best way to solve the problem so far has been to leave and work with people who are not so...
how about not calling it custom code. If instead you call it 'anticipated SharePoint user extensions' or something it may soften the misconception surrounding a specific term.
also, as has been said, there may be other hidden from you reasons that management is pushing this agenda. It is probably best to not second guess these too quickly, as many would be valid.
Finally, there are alot of places that need development. it doesnt hurt to look for a better match.
good luck.
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've read somewhere (I forget the source, sorry - I think the MS Office developer's blog?), that when you do a survey of users asking them about what features they would like to see in your software/website, they will more often than not say that they want every little thing, whereas collected metrics show that in the end, most people don't use 99% of these features. The general message from the blog post was that you shouldn't ask people what they use, you should track it for yourself.
This leads to an unfortunate chicken-and-egg situation when trying to figure out what new feature to add next. Without the feature already in place, I can't measure how much it's actually being used. With finite (and severely stretched) resources, I also can't afford to add all the features and then remove the unused ones.
How do you find out what will be useful to your users? If a survey is the only option, do you have to structure your questions in certain ways (eg: don't show a list of possible features, since that would be leading them on)?
Contrary to popular belief, you don't ask them. Well, you don't listen to them when they tell you what they want. You watch them while they use what they have right now. If they don't have anything, you listen to them enough to give them a prototype, then you watch them use that. How a person actually uses software tells you a lot more than what they actually say they want. Watch what they do to find out what they really need.
Give them options and the have them arrange them in order of importance. As you said, the users are going to want everything, but this will allow you to tell what they want the most.
You tell them. Then both of you know.
(No, your users won't tell you what they want. That's work. If users wanted more work to do, they wouldn't be looking for software to do their work for them.)
An anecdote from a previous life:
We were planning for a new release and wanted to add some new features to the application. We got the users together and brainstormed what things they wanted to see in the system, placing each "feature" on a yellow sticky on a white board. We then grouped similar requests together and eliminated duplicates or near dups.
We then laid each sticky on a table with a cup in front of it. Each user got 10 pennies to "vote" on the features they wanted. They could put as many pennies in each cup as they wanted, up to all their pennies in one cup if they so desired. We then counted the number of pennies in each cup and chose to implement the top 5 vote getters, in order of votes.
It was surprising to see people that were passionate about a feature while brainstorming and categorizing turn around and not vote for that feature (or vote lightly for it).
Of course, a technique like this will only work if you have ready access to your user base (this was for an enterprise system we developed internally).
You ask them.
(No, you do not know what your users want better than they do. Yes, you will get a lot of stupid answers. Avoid multiple-choice surveys and instead opt for reviewing free-form answers. The information you collect will be invaluable.)
Of course — you could always allow your users to vote on which features they like most...
Users know what they don't want better than they know what they want.
We had brought in a team do do an Oracle eBusiness Suite implementation. They took an interesting approach that had worked very well for them in the past. But it was phenomenal in our environment.
We had cultural issues which meant none of the users were going to stick the necks out to say what they wanted. I had history with the users from the past. Trying to get get requirements out of them was like trying to get blood from a stone. But once you went live the bitching would start.
Anyway the implementation team installed Oracle eBusiness Suite straight out of the box. Give the users the basic training. Then about every 4 weeks for the next 6 months they customized the base installation to accommodate the complaints.
I would recommend against showing them options; as you point out, if it's available, then people will want it just for the sake of having it. Often the users are not aware of the extra costs of developing a particular feature, and just want it because you mentioned the possibility of having it.
The other option is to show a list of all the features you could possibly add, and then attach a price to each one, and then ask users, would it be worth $X to have feature Y, or, how much extra would you be willing to pay for feature Y?
Eat your own dog food
Try to use the application that you write yourself as much as possible. Then you will know how you can improve your application.
According to 37 Signals - Getting Real book, you don't do anything, you don't even record what they want, you just delete mails after one read without any action.
When it comes to implement / fix stuff you'll remember the most important things that your users want from top of your head. Obviously this requires a bit user base.
You need to tie features to cost. Everyone wants features, but not every feature is worth paying for. Ask which features are most important, which would your users be willing to pay for? Develop features based on the priorities supplied by users and stop when they aren't willing to pay for any more. Get the product into their hands as quickly as possible so that you can get real feedback on what doesn't work and what needs to be added. When the users have access to real software, you get much better information. This works best when you are developing specifically for a particular customer. If you don't have access to real customers, consider seeding your product with people (can you say, public beta?) free in order to get better feedback.
Users don't know what features they want. You don't know what features they might be offered. "Features" don't mean anything except as they help them accomplish tasks and achieve goals. And that's where you should start, because they will have a very imperfect understanding how they relate.
There is one thing they know, maybe, much better than you do. And that's how to get their jobs done.
As soon as computer/software concepts and terminology start to leak into the discussion between users and designers, you're off the rails.
So many times users will focus their requirements in terms of what's wrong with, or could be improved about, the software they currently use. Over time, even they lose the distinction between their jobs, and the software they use to do their jobs.
It's a very hard, critically important problem for you to solve this.
The only way to know what the users "really" need is to "be" the user.
Its programming kung fu black belt level.
"Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.
Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot it becomes the teapot. Now, water can flow or it can crash. Be water my friend."
When you be the water/customer, you'll now.
I think Bruce Lee would be a good programmer.
Im very serious. This is the way I work. I cant do things I dont understand, so I have to understand before I do things. When I understand, and my costomers know I understand then I can do a good job. Without understanding there will be missunderstandings. You are the only person who know when you have the correct level of understanding, you are also the person who is responsible to get that knowledge.
The Oracle at Delphi
Pros: accuracy is superb
Cons: if you can interpret the messages, which many people fail to do (often seeing what they want to see). Also requires supplication, which can get messy (contrary to popular opinion, your hecatomb need not be 100 of the same type of livestock).
Psychics
Pros: accurate to a point.
Cons: rare. Prone to mental instability, highly vulnerable to eldritch beings, and might attract unwanted attention from them. Also, it takes experience to sort through the mystery that is the human mind to get to desired information. And sometimes you still need to probe subjects while they're actually doing the thing they need help with, since users lie.
Plant a mole
Pros: New gadgets. New Poisons! Plans within plans within plans. Baby's a freak show. You might learn all sorts of fascinating things in addition to the information you need to help the user.
Cons: Expensive. Chances remain that the agent will turn on you, or fail to learn anything you couldn't learn more simply. If discovered, organization will likely turn or liquidate the asset, which represents a huge investment of resources. Organization might reciprocate.
Guess
Pros: Take a group of people with average to great imaginations and problem solving skills, give them some booze and inspire them with some quotes from Ghostbusters, Big Trouble in Little China, or The Big Lewbowski. Who knows where it will go, but it'll be fun and they might produce something interesting/useful.
Cons: Chances of meeting user's needs are higher than you think, but not that good.
Ask the user
Pros: users feel empowered as part of the process.
cons: until they have to decide on anything, at which point you are on your own. Unless the user is a very experienced user, in which case they probably have a good idea of what the want. There's only like 4 experienced users on the planet though, and nobody ever knows anyone who gets to do a job for them. They may be mythical beasts.
Pretend you care and ask the user (even though you don't really), and then observe them doing whatever key workflow/process/etc is involved and pay attention to what they do.
Pros: you trick the users into thinking their opinion matters, which empowers them but doesn't deliver any other baggage. Since users lie - no purposefully or maliciously mind - you actually get to see them in action and get a better grasp of what the problem is, thus giving you a better foundation for building a solution. Also, you avoid the psychic route, and thus avoid a long and winding road that begins with promise but ends with you and the psychic being eaten by some monstrous, unspeakable thing that is not of this world. Observing the process is like totally Zen, which is good for your Developer Mystique.
Cons: No road trip to the Oracle (which would be EPIC). Spies are much sexier; chicks dig spies. Ghostbusters|Big Trouble in Little China|The Big Lewboski probably aren't involved. Feels more like work than the rest of the options.
Asking users about features will prompt them to talk to you about features.
If you want to find out what users really want then you are talking about understanding their goals and motivations. I've found the easiest way to start doing this is user interviews, not about features but about how users use your product and products like it, why they are using it and how it fits in with their life.
Once you build an understanding of what your users are trying to do with your product and why they want to do it you are in a position to make an informed judgment as to whether the features people requested are what they really need.
Ideally I think your problem is about understanding users rather then just listening to their requests.
This is an old question with a lot of good answers already, but I thought I'd just add a little bit of personal experience for the sake of people who end up here in the future through a search like I did.
If your project does not need to gain an audience as quickly as possible in order to succeed (like a webapp) if it's more of an internal project or product to be sold for a fixed client, or type of client, then I believe your best bet is to go the 37signals way: give your users the absolute minimum they need in order to accomplish the most basic tasks of the most basic cycle of work at first, then listen to what they say it's objectively missing in order for them to do their work properly. Not what they want or would like it to have, but what they really need. And the only way you know for sure what you really need is when you don't have it.
I worked as the designer in the development team of an intranet-based "heart-of-the-company" app that followed that strategy, and the results were wonderful. First week: everyone was pissed. When it was over, 90%+ of approval, and the app was still simple and beautiful. And most of the people who were not entirely satisfied seemed to understand why it couldn't be like they wanted, and the main request of nearly everyone was to, whatever we did, keep the app simple.
Again, if you're working on a product or website that needs to attract people first, that might not be feasible or delay things a lot. But if you have some control or leeway over the userbase, I'd definitely recommend this approach.
You don't ask for features. You ask for problems. Pain points. Find out what they hate about their current solution. Find out what eats in to their time.
When you know what they don't like, then you build the solution to those problems.
When you solve real problems, then you're creating real products that people will gladly give you money for.
But what's also important is respecting them during your research phase. Surveys are still great for doing research, but if you ask them a dozen questions, they will hate you. You need to respect their time and use a survey tool that engages them and leaves a great impression.
It's a proven fact users don't know what they want. What you need to ask them is what is wrong with what there is now - what problems are they having with your software? why aren't they using x feature and y control? why interaction x worked for them while interaction y made them try to gauge their eyes out?
Of course to be able to ask those questions, you need to do some field study and see what features are used, what patterns your users exhibit and analyze that data. That analysis will give you the base for much more specific questions which users are able to answer decisively and accurately.
If you're serious, you videotape them at their work, and then you break down what they are trying to accomplish and how your product can help them. This is part of a whole discipline called usability engineering. A good introduction to technique is Jakob Nielsen's book Usability Engineering. Back before he became a shameless huckster, Jakob was a very good scientist and he learned a lot about cheap ways of figuring out what users need. Especially good if you're on a budget. What impressed me most was using paper prototypes; this is a great way to mock up software you haven't built yet and helps answer your question about what to build next. Until I saw this technique in action I couldn't believe how effective it could be.
P.S. One example of what happens if you just ask people: 90% of the feature requests for Microsoft Office 2007 were for features that were already in Microsoft Office 2003. In that case what users needed were better ways of finding what was already there. I wish I could find where I read about this... sorry not to have a reference.
I'm assuming based on your wording that you are building a product to sell, and not building something to order for a specific client.
In that context, I'd say that you should start by becoming a user yourself and building the features you need in the way that you want it. As you evolve the product, you'll need feedback from other users, but this at least this gets you started and breaks the chicken-egg cycle.
As for measuring actual usage of features, you can set up a discussion forum to get feedback on the features you added... you don't need anything too complicated if you are time-strapped.
I personally like the hands off approach from customers. They give you high level requirements and you provide the implementation. Your software team/company/division are supposed to be the experts. Sure you will make some mistakes, if its horrible the customer will pipe up and you will fix it, but generally having the implementation up to you and your developers is a fun dilemma to solve.
Research, research, research. Learn from others designs, then make your own kickass design. Not easy but then again they don't pay developers the big bucks for nothing.
That's a good question.
If you're building an FPS game, you really need to know for yourself what should be included, because 99% of your users will never contact you to say "I wish your game just had X". An experienced beta-testing team can help here.
If you're writing an accounting application, you need to understand the industry and what users are trying to accomplish when they use your product, and try and focus your feature set around those goals.
If you're writing a custom app for 100 users in one business, you could have a chat to the dozen or so most avid users of the software. They're the ones who know all the forms back-to-front, have discovered all the undocumented shortcut keys, and have also figured out how to circumvent many of your data validation rules.
Imagine you are them
Use Cases.
What will they do with that feature?
It works like this.
People take actions. We build software to help them take actions
In order to take an action a person must make a decision. We build software to help them make decisions.
In order to make a decision to take an action, a person needs information. We build software to collect and present information.
Every feature must be an Action, a Decision or Information. And the connection had better be direct. Information that does not lead to a decision or an action isn't even "nice to have" -- it's junk.
Users say a lot of things. What do they do? What decisions do they make? What information do they need?
Edit
Note that not everyone is good at describing use cases. Some people have no vision and will simply tell you what they do today without understanding how they are creating business (or personal) value. They may not really know what decisions they're supposed to be making, and are vague on the information they need.
Other users know what value they create, and why, and can discuss use cases well. They can envision alternative ways to create value; they can articulate options for their actions. Decisions don't have a lot of alternative implementations (people make decisions, not software) and the information required doesn't change much, either.
Watch them.
Identify bottlenecks in their work
Create something that solves that
bottleneck in an elegant way
Let them use it
Repeat until everyone is happy
Based on the principles:
Users know what they want, but they
don't know what they really need.
You ARE
NEVER going to get it right the
first time.
It seems like a chicken-and-egg problem. Much like computing PageRank. A page's page rank is dependent on the PageRank of other pages linking to that page.
One way of computing PageRank is by iteration.
Iteration is the key!
A. Voting
Gather a biiiig list of features all users want (make them enumerate each feature they want).
Then have them review the list and allow them to vote on features. Say, give em 100 points to distribute on features. They can give more than 1 point to a feature.
B. Analysis
Analyze the business model, List the features that you think is needed.
This is needed because:
users sometimes don't get the big
picture
you have this REALLY great
idea that users won't think of in a
bajillion years.
C. Implement
Analyze list from A and B, merge, remove a few, improve some. Implement.
D. Test
Test it on users. Hear their complaints. Look at
- features they use often
- stuff they get stuck on
- etc etc etc
E. Iterate
Usually, users do not always know what they want and whether they want anything. In our company sales people go to existing and potential customers, show them our product and explain them why they desperately want that.
In my time in university we were taught something called "userp-driven development". Here you really have to go to the customer, observer how people there work, what tools do they use, and try to find out what could facilitate their life. You then create a mock-up, go to the customer again, present it to the users, get their feedback and then proceed to improve your mock-up. When everyone more or less agrees to the course of action, you do implementation, regularly showing the customer what you have trying to get correction feedback as early as possible.
Important is not to talk to the managers who want the product, but to the users who will use the product. Otherwise the whole play will bring you nothing.
P.S. Asking them directly "What do you want?" could be a dangerous question...
Babylon 5 - What do you want?
It's called Market Research.
No, this wasn't a dig at the guy, that's really what it is about. Sure, there's a bunch of techniques that UCD people use in the field to get user requirements, but they are exactly the same tools used by market researchers. Card Sorting, Priority lists and so on are all market research terms.
This question already has answers here:
How do you protect your software from illegal distribution? [closed]
(22 answers)
Closed 5 years ago.
Besides open-sourcing your project and legislation, are there ways to prevent, or at least minimize the damages of code leaking outside your company/group?
We obviously can't block Internet access (to prevent emailing the code) because programmer's need their references. We also can't block peripheral devices (USB, Firewire, etc.)
The code matters most when it has some proprietary algorithms and in-house developed knowledge (as opposed to regular routine code to draw GUIs, connect to databases, etc.), but some applications (like accounting software and CRMs) are just that: complex collections of routine code that are simple to develop in principle, but will take years to write from scratch. This is where leaked code will come in handy to competitors.
As far as I see it, preventing leakage relies almost entirely on human process. What do you think? What precautions and measures are you taking? And has code leakage affected you before?
You can't stop it getting out. So two solutions - stop people wanting to hurt you, and have legal precautions. To stop people hating you treat them right (saying more is probably off topic for stack overflow).
I'm not a lawyer, but to give yourself legal protection, if you believe in it, patent the ideas, put a copyright notice in the code, and make sure the contracts for your programmers specify carefully intellectual property rights.
But at the end of the day, the answer is run quicker than the competition.
Unless you're working with something highly classified and given that you can't block email and USB devices I guess you aren't there's really not to much damage to be had even if the source code leaks. The thing is, what is the code, or parts of it worth without the knowledge of how it works and the organization around it.
In general the value of "source" is much less than is commonly touted, basicly the source without the people or the organization isn't worth the storage it occupies for a competitor.
Also, you're missing the most likely attack vector, and it's also the one you can't stop no matter what. If someone really really want's to know how you made your magic then they'll try to hire your developers away, and since you can't stop them from having information inside their skull and even if they turn in all their possesions ther knowledge and domain expertise is leaving with them. Basicly employee retention and trust is the only way. Sorry.
I don't know how much actual help this is going to be, but:
Don't p*ss your programmers off. Don't get them in a position where they want to give the source to a competitor. Most places undervalue their developers. Given where you are (SO), I guess you are less likely to. Nothing got to me more than seeing the sales folks out for games of golf - paid, and paid for, by the company - while we had to fight to get pizza once a month.
Really, if your direct competitors got your code today, what would it do? Is your product or vertical market that stagnant that you wouldn't release newer, better versions before they could react? Is there no room for innovation? Most companies overvalue their "proprietary algorithms and in-house developed knowledge". Sure, it may cut some time off, but it's only about 10% of the problem.
If you got all the source for all your competitors products, how much actual use would it be? I'd guess it would set you back months. Not forward. Back.
If you had a clean system, and little external/internal knowledge, how long would it take you to get your own product into a buildable state? How long would it take to drill down into the code and workout what is going on? How much time and money would you waste trying to work something out, rather than spending time and money on how to make your product work better?
I've actually been in the position of having all the source - 1million lines+ of code - to a competitor's product. We did nothing with it - aside from a bit of a poke-around and then delete it, which was more than I was comfortable with - but I would expect that we'd have chewed up months of time just to get to where they were then.
So we nuked it, slapped the id10t who got it (yes, a developer/PM who came over from the other company), and thought about how to make our product kick so much butt that it didn't matter what they did. Much better use of time. Worked well, too. We had differentiators, not just re-hashing the same features in the same way they did them.
Sorry, but there is no way you can stop people getting stuff out, and still be able to actually work. You can stop them wanting to do it, or make it so there is no value to them having it.
We were worried about people decompiling our code too. We stopped worrying when we realised that WE had enough trouble working out what was going on inside 500K+ lines of C#, C++ and HTML code talking to MAPI/Exchange. If someone can decompile it and work it out, then we want to hire them......
BTW, for clarity, and given who I now work for, I should point out this is not my current employer. This was quite a while ago.
The code does not leak out on itself. It takes people to take it. There are obviously some security measures you might use like traffic analysis and lock-down on the repositories so only authorized developers can connect to it.
But by the end of the day your best option is to make sure that no one WANTS to steal from you. Your team has to be happy, they have to be proud to work for your they have to be loyal to the company and to each other. If you have such team it's a simple question of explaining to everyone that the code has to be protected from outsiders. It will not stop a dedicated mole but will prevent accidents.
P.S. And yes, proper clauses in the contracts would not harm as well, at least they will make sure that the developers are AWARE that taking code outside is morally wrong.
Follow these guidelines and it shouldn't matter if the contents of your entire source code repository is posted all over stackoverflow:
http://geocities.com/mdetting/unmaintainable.html
Oh, and show your developers that you don't trust them by blocking access to parts of the source code, scanning outgoing/incoming email etc. That is a surefire way to make them want to stay around... ...nothing improves morale like a bit of mistrust in the workplace.
Another cool way is to tell one half that they are "team a" and name the other half as the untrustworthy "team b". Then reverse it and say the same thing to the "team b" members. Encourage them to keep an eye on the "bad guys" in the other team and to report any signs of illoyalty to you. Sprinkle a few "conflict inducers" (e.g. tell "Joe": 'do you know what Ed says about you behind your back?') etc. Works wonders if you set up the developers against each other and create a few [invented-by-you] conflicts here and there...
(Eh, and no, I don't actually recommend any of the above. Just kidding. But I have seen people use all of the tactics above. And it didn't work.)
Okay, I am going to be a little practical here.
Being nice to everybody and hoping they won't hurt you doesn't work.
Every programmer knows from the day he joins a company that he'll not stay there forever. He will change when he's learned enough to get a better opportunity.
The programmers who write the code believe that they have the ownership to it even if they wrote it on the time they rented out to somebody else. So many of them will usually try to get their hands on the source-code even if they don't intend to hurt anybody.
Once they leave the company and they've carried the source code with them and lost contact with their colleagues, the conscience settles down and goes on a vacation and after a while bits and pieces from the code start showing up everywhere.
That's what I KNOW happens cause I've witnessed it happen to my company.
So what does one do?
Sign a NDA which specifically mentions that they programmer WILL not take copies.
Distribute your product between programmers, and if possible get modules coded individually and integrated by a chief whose responsibility is that all programmers do nt get all the code.
At the time of termination get a written undertaking from the coders that they do not possess any IP of the company and they understand the penalties of violation.
If somebody violates your IP, sue the man! No exceptions. It'll work as an example for the present team.
Do I sound extreme?
I remember this happening to Valve when they were developing HL-2. Interesting link here: http://www.shacknews.com/onearticle.x/28619
Most of the answers are based on Moral and ethical values. I wonder if Google, Facebook etc. just rely on their employees good will. Give me a break, that's totally utopian. Don't be a fool. Be realistic.
YES, it is possible to prevent code leaking:
Using a virtual server hosting virtual machines, programmers can only access locally to these virtual machines (intranet) via Remote Desktop. Repository is managed locally. private keys are required to access the repository. Copy/paste from virtual machine to client is disabled. only copy/paste from client to virtual is allowed.
Companies like facebook do that.
The only way to still code is by taking pictures to the actual code, which is totally not practical and feasible at all, and since there are surveillance cameras everywhere, you will have to go to the bathroom to take those pictures.
I've worked somewhere where there was a real culture of secrecy about this sort of thing (historically there had been a number of times when the company was small where "customers" had, shall we say, abused their access to our product).
While at the top the management were very protective, I see it slightly differently. I think our code, while not entirely irrelevant, isn't as key as you'd expect it to be in a software company.
The reason that we are successful is:
1) The code is essentially the solution to a bunch of problems. If you get our code you get those solutions but we still have the smart people who solved those problems. They understand those problems better than you do and are better able to solve the next set of problems better than you are.
2) Because they really understand the problems (and the solutions) we can do things faster than our competitors which translates to cheaper (or more profitable).
3) Also because of those people and the attitude within the company we've delivered well to our clients and provided good support.
4) And because of that we have a good reputation and reference-able customers.
A small number of companies have code which is genuinely worth keeping secret - proprietary algorithms and that sort of thing - but for a vast majority of us our products are very easily replicable by smart people.
What I'm saying is do the basics - write it into people's contracts that they can't take it, keep it secure and so on - but don't obsess over it. Unless you're in a very specific market it's unlikely to be what's really going to make your business succeed or fail.
The best step starts from reruting guys with strong ethical behaviour.
Various other steps can be taken like all communication being scanned. There are places where email and all information going out is scanned. The desktop/laptop does not have hard-disk or the access is restricted and all work is on network folders, even when working from home, one has to get connected to internet. The offline work gets synchronized. The USB and drives are disconnected.
The other policies are to provide access only on need basis.
These will only slow down and hinder to some extent, but is one is very determined then he would find ways to get around this.
The other way is if the code is really very important, then have the idea copywrite protected legaly.
To be honest it's almost impossible. If I wanted to suggest what a company that would shortly appear on the Daily WTF would do:
Disconnect the "work computer" from the internet, bt because they need internet access for reference buy everyone a wbbook.
Stuff the developers USB slots with epoxy and require that they load/unload everything from a centralised server, which scans all the data that goes through it for code like syntax.
Or you could just trust your employees and make them sign an NDA...
I personally never tested on any real case, but I would suggest using code fragmentation:
basically you split your project in a number of libraries, define interfaces and unit tests for each of them, then you separate SVN repositories so that each group have access to a limited part of your precious source code.
This is also a good practice no matter what and should help if you are outsourcing abroad.
The previous answers all seem to center on building trust and employing ethical people.
Another possibility might be to create your own domain specific language and tools. That will make any leaked code harder to use. It might still be possible to steal useful ideas from it, but it would not be possible to simply compile a competing product unless the whole toolchain is leaked.
Trust your developers. People tend to live up or down to expectations. Treat them well, and remember that loyalty goes both ways. After all, if you can't cut off thumb drives, you can't stop anybody from leaking code, no matter how much you don't trust them.
That being said, find yourself a lawyer with trade secret expertise, probably expertise in other parts of IP law, and ask how to legally safeguard stuff. You do want to make sure that, if a competitor gets your stuff, it's not legal for the competitor to benefit from it.