Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
In pair programming, the experience of every member of the team can be spread to new member. This experience is always in sync with the code, because the "senior" of the pair knows how the code works and what the design is.
So what is the utility of design documentation in this case ?
UPDATE
I don't imply no design, I imply no documentation.
With a team which practice pair programming I think that everybody is disposable, because everybody knows the code. If the senior developer leaves, I think that there is always at least one person who knows the code, because the experience was shared before.
What if your team is larger than 2 persons?
Just because two people know a part of a system does not mean it shouldn't be documented.
And I would be glad to know that I don't have to remember every tiny detail of a system just because it it's stored nowhere else than in my head.
For a small system this might work, but as the system gets larger, your limiting yourself and your colleagues. I'd rather use the memory capacity for a new system than to remember everything of the old system.
Have you ever played "telephone?" I don't think you should play it with your codebase.
What if the senior programmer leaves the company/project?
The set of deliverables should be decided independently of whether you use pair programming or not.
Six months or two years later, all the people involved could be in a different project (or a different company). Do you want to be able to come back and use the design documentation? Then, produce it. If you don't want to come back, or the design is simple enough that with the specs and the code you can understand it without the aid of an explicit design document, then you may skip it.
But don't rely on the two people explaining the design to you one year later.
Maintenance. You can't expect the team to remain static, for there to be no new members or loss of old members. Design documentation ensures that those who are new to the project, that have to maintain it years down the line, have information on decisions that were taken, why the approach was chosen, and how it was to be implemented. It's very important for the long term success of a project to have this documentation, which can be provided via a combination of traditional documents, source comments, unit tests, and various other methods.
I don't see that pair programming makes design documentation obsolete. I immediately have to think about the Truck factor. Sure, the senior may know what the design is. But what happens when he is ill? What happens when he gets hit by a truck? What if he is fired?
Pair programming does spread knowledge, but it never hurts to document that knowledge.
Who knows about the first-written code? The answer is nobody knows, because it hasn't been written. The reason it hasn't been written is because nobody knows what to do, hence the need for a design document.
Pair programming is just two people sharing one computer. By itself, it says nothing about what kind of design methodology the pair(s) uses.
Pair programming, when taking as part of "Extreme Programming", means following the Extreme Programming guidelines for design. This typically involves gathering and coding to "user stories". These stories would then stand in place of other design documentation.
The experience of people may be in sync with the code, as you say. But the design decisions are not all captured in the code - only the choices made are there.
In my experience, to really understand why code is designed the way it is, you need to know about the design choices that were not selected, the approaches that had tried and failed etc. You can hope that the "chinese whispers" chain transmits that correctly, given that there's no record of this in the code to refresh memories or correct errors...
... or you can write some documentation on the design and how it was arrived at. That way, you avoid being taken down a dark alley by the maintenance programmers in future.
Depends what you mean by "design documentation".
If you have functional tests - especially behaviour-driven development (BDD) tests, or Fitnesse or FIT tests then they're certainly a form of "active documentation"... and they certainly have value as well as being regression tests.
If you write user stories and break them down into tasks and write those tasks on cards for pairs to do then you're doing a form of documentation...
Those are the two main forms of documentation I've used in XP teams that pair on all production code.
The only other document that I find quite handy is a half-page or so set of bullet points showing people how to set up the build environment for a development machine. You're supposed to maintain the list as you go along using it.
The code base may be so large you can't humanly remember every detail of what you were intending to implement. A reference is useful in this case.
Also, you need a design if you are interacting with other components etc.
Well if you want a spreadsheet program instead of a word processor a design doc use useful :-)
XP, pair programing, agile, etc... do not mean you do not have a plan, it is just a far less detailed plan (at the micro level) of what is going on. The use cases that the user picks are more of the design, and it is more of a living document than with other styles of design/programming.
Do not fall into the trap that because youa re doing something "cool" that you no longer need good practices - indeed this style of programming requires more discipline rather than less to be successful.
Pair programming is an opportunity for the team to avoid having to spend a large proportion of the project time on documenting everything. But the need for documentation depends on how good you are at remembering the important stuff and how good your code is. You may still want lots of documentation if the code is difficult to work with.
You could try some experiments:-
Document a couple of small parts of
the design and note how often you
have to refer to it.
Document stuff that is always a pain
to work with.
No Nor does lack of pair programming mean you need documentation. Documentation is needed! What it looks like may surprise you!
An agile team will decide when and what documentation is needed. A good rule of thumb, if no one is going to read it, don't write it. Don't get caught up in the waterfall artifact thinking by provide artifacts because the Project Manager says so.
Most think of documentation as something you do with Word. If an agile team is working properly, the code itself, with TDD (test driven development) will have a set of automated test that document and enforce the requirements. Image, documentation that is in sync with the code ... and it stays that way.
Having said that, pairing does help domain, application, practice and skill knowledge propagate through the team very quickly. Pairing also helps ensure that the team follow the engineering practices including TDD and other automated test. The results are that the application remains healthy and future change is easy to bring about.
So, bottom line, pair programming produces better documentation. It does not eliminate documentation (although you might not be able to find a Word document).
I am a pro-advocate and a fan of documentation. Pair programming does not require "one senior developer". In my experience with pair programming, developers of all levels are paired together, for the purpose of rapid development. There are many times I worked with junior developers and would trade off on the keyboard. There are many times I worked with senior architects and would trade off on the keyboard. Documentation is still necessary, especially with your core components and database.
Pair Programming only enables your coding and logical aspect.
But documentation is good practice. Always do documentation...
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work as a lone developer in a very small company. My work is quite chaotic and I'm looking for ways to make it more organized.
One problem is that my projects have practically no management. Rarely anyone asks me what I'm doing, or if I have any problems. At some point there was talk about weekly status meetings, but that's some time ago. Seems that if I'd want something like that, I would have to arrange those myself.. Sometimes I'm a bit lost on what I should do next because I don't have tasks or a clear schedule defined.
From books and articles I have found many things that might be helpful. Like having a good coding standard (there exists only a rough style guide which is somewhat outdated in my opinion), code inspections, TDD, unit testing, bug database... But in a small company it seems there are no resources or time for anything that's not essential. The fact that I work in the embedded domain seems to make things only more complicated.
I feel there's also a custom of cutting corners and doing quick hacks on short notice. This leads to unfinished and unprofessional products and bugs waiting to emerge at a later date. I would imagine they are also a pain to maintain. So, I'm about to inherit a challenging code base, doing new development that requires learning a lot of new things and I guess trying to build a process for it all at the same time. It might be rewarding in the end, but as not too experienced I'm not sure if I can pull it off.
In a small shop like this the environment is far from optimal for programming. There's many other things needed to be done occasionally like customer support, answering the phone, signing parcels, hardware testing, assembly and whatever miscellaneous tasks might appear. So you get the idea about the resources. It's not all bad (sometimes it's enlightening to solve some customer problems) and I believe it can be improved, but it's the other things that I'm really concerned.
Is it possible to have a development process in a place like this?
Would it help to have some sort of management? What kind of?
Is it possible to make quality products with small resources?
How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Maybe there's someone working in a similar shop?
Use Source Control for EVERYTHING
Develop specifications and get signoff before starting - there will be resistance, but explain it's for their own good.
Unit tests! It hurts because you just want to get it done, but this will save you in the long run.
Use bug tracking - Bugzilla or FogBugz if you can afford it.
My advice is not to be extreme. From my experience, pure agile or pure traditional will not work. Before you use any process, know what it mean to solve.
I personally use a variation of Agile RUP. I do some upfront effort such as investigate the actual needs, do high-level design with possible extension. And ask customer to sign-off some major high-level requirements.
If you work in small group, detail design or specification may not worth. Of course, if there is some libraries that are shared by many, it will be worth the trouble.
Deciding what to invest in up-front depending on its risk (likelihood and effect).
Moreover, many SW best practice is really 'best' like version control, automatic testing (to me I only used it way to early detect regression as I do not believe in TDD as driven force of the development). I suggest you read 'Pragmatic Programmer' it presents many of those techines.
As to answer you questions:
(1). Is it possible to have a development process in a place like this?
Yes, but as I say, trailer it to fit your organization.
(2). Would it help to have some sort of management? What kind of?
Management helps but no control freak. Plan what to do when: integrate, resolve conflict, dead line of some mile stone. And roughly keep them on schedule (I particularly like Scrum's sprint).
(3). Is it possible to make quality products with small resources?
Definitely as soon as the size of the work, the time to develop and the size of the team is balance. If you definition of Quality is the same with me. To me, Quality means: solve the problem it set out to in an efficient and reliable fashion.
(4). How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Point out the problems. If there are none, why change? If you want to change, you should be able to identify the problem OR potential problems. Point out the problem.
Some big one are:
Without any process, it is harder for new recruited to blend in as they must learn from observing other how to deal with things.
Without process, it is harder to work in stress.
Without schedule, it is hard to determine the progress.
Without automatic testing, it will takes more time to identify problems and regression.
Without version control, it will be harder to roll-back mistake and separation of work to each team members will be mess.
Just my though.
You need to work with the owner and setup short medium and long term goals. You will want to let them know progress even if only through email.
You will need to enforce some order on your workday or you will never get anything done (those long term goals).
Divide your day up into chunks when you can code, when you are working on hacks to keep it togther, when answering emails etc.
Definitely setup a bug tracker. This can help keep your email clean. You can even setup an email address to forward bugs to be categorized later. This is good because the bug reporters will eventually tire of the bug tracker and want to just email you the bugs anyway.
edit
And as lod3n said, source control, but you are using that already right???!!?!
Been there, done that.
The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.
Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.
lod3n is absolutely right about Source Control.
I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.
Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.
Have a bug tracking system, both for defects and new features. Don't rely on your memory.
Continuous integration and an automated build can help even a single developer.
Can't emphasize the recommendation for source control enough.
I've decided I don't need unit tests because I can have automated functional/integration tests instead: because with incremental development there's no need to test before integration.
as crazy as this sounds I use scrum just because I like the concepts of sprints, and backlogs. It makes it easier to set realistic goals. Of course the idea of scrum master and team is all you but if you are working on outside projects where it is possible that you may pick up an extra team member with your backlogs it will be easy to distribute work. Maybe I just like backlogs. With scrum you will need to get someone to be the product manager to talk about the features of the product. Version control is a must at probably should be implemented b4 even worrying about a software development process. I have worked in a company that started from 2 developers and went to 12 in a year. We started with no version control and low coding standards. The changes you will need to make will be gradual so don't worry about rushing to do a 180. Set a goal to change one thing a month and find supporters of your changes to make things go smooth.
As well as the recommedations of others I'd say that if you are tight on resources but have more say over how things get done you should make good use of off the shelf and open source products and libraries. This leverages the efforts of others, saving you time, ensures your code base doesn't become too esoteric and adds to your skillset so you don't end up being an expert in something that's useless everywhere else.
First, lets make a distinction between a development process and best practices. Best practices like source control, defect tracking, unit testing, etc. are an given.
Then there is the actual development processes. I would always recommend having a process, no matter small or large the team is. The trick is finding the right process. You have a process now - it is just an ad-hoc process that doesn't seem to be working out too well for for you. Rarely can you take a textbook development process and directly apply it. What you need to do is tailor the process to your companies needs and culture. Look at as many development paradigms as you can and try to find something that is a good fit and them start molding it to your needs. You may have to try and fail with a number of different processes. Perhaps the Personal Software Process will be a good starting process, maybe an agile process, a variant of RUP? You have a lot of options, start trying them out.
You are also going to have to work with the rest of your organization - they need to be a part of the process. You may be the lone developer, but a development process involves more than the developer, it involves ever person that has a say or impact in the product.
This may not be a specific answer, but my point is that you will need some kind of process. So start researching them and trying them out and molding them to your needs until you have something that works.
When writing code for a new system I don't want to introduce unnecessary complexity in the design that I might never have any need for. So I'm following YAGNI here, and rather refactoring as I see the need for more flexibility or as responsibilities becomes more clear. This allows me to move faster.
But there is a problem here with junior devs, in that they will not recognize when to refactor or where build out the design. They just stuff more code into the existing design.
So, what are the best ways to tackle this? Should I more often build a more future-proof design so when adding to it they have a good example to follow, even if we might never have to add anything? Or should I just go ahead with more code reviews, education, etc? Or both?
Have any of you had any experience with this type of problem? How did you solve it?
I would recommend code reviews or pair programming. It gives you the chance to educate your fellow developers and increase the overall quality.
Perhaps you begin by recognizing explicitly that part of your job is to help develop the junior devs. If you're not the boss, management should sign off on this. Management needs to recognize that your choices are to develop them now or clean up after them later, and you need management's backing for the time this will take.
Code reviews and pair programming are fine ideas. They are especially good because they are not "just for junior people"–I do both with one of my close colleagues; together we are nearly 100 years old and have more than 70 years of programming experience :-)
But there's a larger problem here: the programming methodology that enables you to be most effective (YAGNI + refactor) is not effective for your junior partners. My experience is that it takes people years to learn the benefits of YAGNI, so if you expect them just to learn your way of doing things, you are setting yourself up for disappointment.
I would encourage you to identify some methodology that you think is going to be useful with your junior partners. The particular methodology probably doesn't matter (heresy!); I've had success with composite/structured design, object-based design, algebraic specification (!), and extreme programming. But
Do pick something that has a name and some literature devoted to it, that your juniors can take pride in learning, and that is a skill they can carry to future projects.
In order to show that it is tasty, you may need to eat the dog food yourself. Pick something you can live with and be productive in.
Observe your juniors carefully and teach them a decision procedure they can use to identify when they should ask you for guidance.
Good luck!
There is a reason they are junior and you are senior.
The ability to realise when a change in design is needed is one of them.
I would carry on as you are but encourage them to come to you when things are getting difficult. You can then work with them to alter the design if needed, this will be easier for you than refactoring it and will help you pass on knowledge to your junior developers.
A very good way to show how far to build out a design is to be specify about what the design will do when built out, then write tests to cover the new functionality. When the tests pass, development is done.
You might realize along the way that you forgot to test for something. That's fine, and is useful feedback to help you specify better next time. Write the missing test(s), and only enough code to make them pass.
Then refactor. Knowing what to look for when refactoring takes a bit of practice. Start with
Is there duplication in the code we've just written that we can eliminate?
Is there duplication between what we've just written and pre-existing code?
Does the code we've just written concern itself with too many things? (I.e., should we break out collaborators?)
Repeat this a few dozen times, and it'll get easier.
Another way of looking at YAGNI is that any changes to code need to be justified.
Might it be helpful to require any commit needs an associated unit test (or BDD user story, choose your poison)? It helps to communicate your intent (you want people to think about why they are adding this feature) and you get regression tests for free.
Also gets the noobs to start thinking about modularity (usually needed to make your code testable) and will help a lot if you do need to refactor later on.
I'm all for code reviews and teaching, but I think futureproof design is also important. Maybe you could think of it in terms of you designing an API and the junior developers using the API. In this way you are the one who does the hard work that they would screw up (identifying duplicated code and eliminating it) while they do all the grunt work that isn't a productive use of your time.
Of course this has to be balanced with a need to develop your junior developers skills. Neither side of the equation can be neglected.
It may help to map out what work they will do and then verify it to help build their sense of judgement which is really what you are asking, to my mind. Pairing is one option but if you can't spare that much time then having a sort of "check point" to see how they are doing and preventing them from going down the wrong path.
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.
Apologies if this has been covered frequently, but I was wondering about how other people approach personal task management.
I've read (parts of) GTD, proceeded to get excited, installed a tonne of plug-ins all over the place, then let it all fall by the wayside. I've used todoist, outlook, google calendar, project. I've tried writing lists in a notepad, in 'notebook', on post-it-notes and in spreadsheets etc. None of it lasts.
Why is a simple and effective todo application so difficult to find? Because the application is so frequently used, I find that any small niggles with the application become overly exaggerated after a few days use.
So far, my favourite application is a variation of todo.txt called task
What do you use?
Sorry to be the bearer of bad news, but a "simple and effective todo application" is so hard to find because you are using the tool as a substitute for self-discipline and commitment. Statements like 'I've read parts of this and tried that and that and that but minor interface issues cause me to drop it in a few days' imply that you are looking for magic bullets and excuses.
Minor issues with the tools are a poor excuse to abandon the effort.
Pick a system and a tool and stick with it
No tool will give you the self-discipline and commitment necessary to change your habits
personal time-management is about changing your viewpoint and habits, not finding the "right" tool
caveat: some systems are more suitable than others for your personal work requirements. If you're a developer, a calendar-based system like Franklin Planner is probably not going to work, while a list-based system like GTD probably will.
Suggestion: google and review the various systems, pick one, and commit to it for at least a month. Try GTD and pen-and-paper, for example, then get fancy once the system is a habit. Once you know how you need to work the system and are committed to it, look for the perfect tool. In the meantime, the perfect tool is the enemy of the good practice, to mangle a quote ;-)
I use text files. Each contains a list of projects, separated by blank lines. Each line of a project's space includes syntax like:
'-': Item of interest
'*': TODO's
':': Code changes
'AWT': (Awaiting something external)
Text files live together and projects move in and out fluidly:
work.txt: Current work / active projects
deferred.txt: Stuff to do someday
done.txt: Finished; archived for records
The text file system is fast, effective, globally compatible and loads in a fraction of a second.
I think I'm like you (were, 2 years ago): too lazy to do anything until I find the perfect tool for it..
Yes, folks saying tools should never be mistaken to be a substitute for executing the plan, are absolutely right...
That said, one tool that seems "perfect enough" for me to drop thoses excuses for GTD: org-mode for Emacs. I really hope so, anyway.
I think this is almost a duplicate of How can I apply David Allen’s “Getting Things Done” as a programmer?
See also:
What Can Someone Do to Get Organized Around Here?
Time management tricks, tools & tips
What do you use to keep notes as a developer?
ToDoList is also an alternative
This is related to Task/issue tracking system with command-line interface which also mentioned todo.txt
Personally, I use the to do list on my Palm PDA, which syncs with Apple iCal.
I'm experimenting with better managing my time. I like starting out simple and building to complexity as it's required, rather than implement some behemoth bollocks that's hard to maintain.
To that end, i use simple lists.
http://tadalist.com
it's stupidly simple, free, and internets based so it follows me everywhere. winner
In our company we use Google Docs Spread Sheet - it's great beacuse you put all tasks into cells and you can share and coedit this document with others. It's very easy to use and doesn't require you to fill a lot of forms.
I use a sticky notes program called NoteZilla
Just scratch your task/idea/notes and forget about it. This is why I like sticky notes. No need to categorize, group. All that can still be done in NoteZilla.
I use TiddlyWiki. It's simple to use, all in one html file (so very portable).
It works great for me.
I'm echoing the above comment to some degree. For me, the tool is pretty much secondary to establishing the mindset and habits that would allow me to incorporate GTD principles in a consistent fashion. I really do love it, when I can get it to go. There's a nice sense of control and direction that comes when I can be disciplined about doing the small stuff - weekly sweeps, periodic reviews and all that.
My next GTD challenge is to get out of the trees so I can see the forest. :-) David Allen talks about the 50,000 foot, 30,000 foot, 10,000 foot views relating to goals. It's all very high-minded, but I have to get above 500 feet yet.
If you're familiar with GTD, there's a nice summary deck PDF over at DIY Planner:
http://www.diyplanner.com/diyp_official/diyp3cl/diyp3_gtdref_cl_2up.pdf
If you're a paper planner junkie (I am) the site's like crack :D
Hope it helps.
I use myLifeOrganized. The bottom line is you just need to start documenting the next thing you have to do on each task. MLO lets you easily and quickly do that.
It has a handy rapid task entry dialog and you can quickly enter data into it. You can document as much or as little as you want. This software, because of the ease of adding stuff to it, has saved my butt many times. It has helped me remember things that I had forgotten. I now wonder how many things I've forgotten over the years and didn't realize it.
I run it off a usb stick and I have it on my phone. I even use it to help me outline code.
As others have said, GTD is all about discipline: actually doing the things on your list. But, be sure to prioritize.
For my task list management, I currently use Remember the Milk, which is fairly handy with its IM integration (it sends IM reminders). My biggest challenge has been remembering to add the tasks, but I'm getting better at it, since somebody pointed out I could make a recurring task to remind me :P.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Do you find that corporate buzzwords or heavy management jargon gets in the way of software project communication? for example using words such as
Mainstreaming
Holistic
Contestability
Synergies
etc.
Would you rather see a initiative within the industry to put a stop to jargon such as this to help people communicate better and keep project communication in plain English? Is it even a problem? What are your thoughts/anecdotes?
I actually like buzzwords, when they are used in moderation.
They became buzzwords for a practical reason: Even though the concepts may be very complex and/or abstract, there is a consensus on the meaning. So with only one word, you can convey a whole lot of information to a large group of people. I see it as a form of encapsulation of information.
(Notice the use of the slightly outdated buzzword encapsulation?)
Of course, that is exactly the reason why many people start to abuse them: They only convey the general concept (i.e. why it's great to do FizzBuzz), and avoid discussing the messy details (i.e. why it won't work).
And since using a buzzword gives the impression that you are deeply familiar with the subject at hand, it can be used to silence others in the discussion.
Conclusion:
Buzzwords are ok - if they are used in the right way. If you want to improve your team communication, train them in the proper use of buzzwords.
I think some kind of industry-wide initiative would be impractical as jargon is in the eye of the beholder.
I think all you can do is make sure that you don't use buzzwords yourself even when communicating with people who do. For example, use the word "people" when talking to a Project Manager who refers to you and your colleagues as "resources".
The use of technical language can both help and hinder project team's progress, depending on appropriateness.
First it's necessary to point out that what is considered "too technical" depends purely on perspective. "Mainstreaming" is as much of a technical term, as SSD, CORBA and SOAP. Something that sounds as jargon nonsense to one person is actually a shortcut to communicate a complex concept for another.
Software development as a rule is cross-domain activity involving in addition to the software knowledge one or more technical user domains. It is a big mistake to assume that sales, marketing, management and banking (just to name a few fields often incorrectly considered "non-technical") haven’t developed and advanced their own complex body of knowledge, in other word — technology: sales technology, marketing technology, management technology and banking technology.
And it’s project manager’s responsibility to facilitate productive communication between representatives of different technical domains. Some suggestions:
Make handy a project dictionary that can be accessed and updated by everyone involved.
Ensure that common denominator language used for cross-domain documentation (i.e. functional specs).
Introduce domain specific terms only when necessary, but then always provide a brief explanation of the meaning (don’t “build from scratch” —leverage the wealth of online encyclopaedias by linking where possible).
Make sure that there is common understanding amongst the project team of the key terms.
Remember that what is considered “technical” depends purely on perspective and you need to facilitate communication in all directions, not just one-way (which is often from software developers to business users).
At the end the software will have to work in the realm of users and you have to make a judgement on how much the UI will rely on specific domain language (this is going to be a trade off between easiness-to-learn and usage-efficiency).
Technical jargon (ORM, TDD etc.) makes one's speech more precise. Corporate buzzwords (aka management jargon), on the other hand, are designed to be able to express vague ideas when full information is not available.
As such, management jargon serves its purpose pretty well, in the sense that it does allow managers to effectively communicate about thins they have very limited understanding of. That said, good manager knows when NOT use the jargon, such as when talking with developers, or with executives, both of whom hate bullshit.
Based on the above, the (Anti-)Buzzword Movement, should rather increase awareness of the proper usage and application of management jargon, and encourage proper information encapsulation only with appropriate auditory.
Personally, I think that the jargon should be used more. I see this occurring more and more and IT people want to simply hide behind the technical elements of the world and act like it is completely the business folks responsibility to speak more geeky.
I'll be honest, speaking more GEEK is not something that the business people can do and you should not want that to occur. Learn the jargon. Become one with the jargon. Own the jargon. Then the next time you are discussing things, you'll not be back pedaling.
Take ownership of the business terms and apply them to the technical side of things...
What's wrong with "holistic" or "synergy"? These are normal plain English words.
Every field has it's own jargon, and that must tell us something - people like having special words, phrases or assigning special meanings to existing words that are only relevant within their own field. I suspect if we went back to the pyramids, there'd be a full set of architectural and building phrases that your average Egyptian just wouldn't understand. So banning jargon just wont work, creating an FAQ and glossary normally do the trick.
BTW This must be a case of pots and kettles. Does anyone outside IT think phrases like - "...We'll use an ORM, and then WCF will talk over HTTPS, throw in a bit of AJAX and some clever CSS on the client and we're laughing ..."
Absolutely. Since managers only talk in general, and we as developers want to understand the precise meaning. I personally fall asleep trying to read abstract writing filled with buzzwords.
The worst being SOA. Neither academic folks nor managers understand it though both use it extensively.
I can't stand buzzwords. One person's "encapsulation" is another's Orwellian destruction of language. Buzwords appeal to the same people who like "decks" rather than memos. For something to act as a representation of many possible things [e.g. "leveraging resources" can mean pretty well anything from using double-sided printing options to drafting people for the Army] there is necessarily going to be a dilution of meaning. If a senior lawyer in my firm were to ask me to "leverage the resources, then run it up the flagpole to get the ducks in line", I'd know that he was tossing back the Johnny Walker at lunch.
Conversely, if I were to respond to a senior partner's memo request with emtpy catch phrases such as those above, I'd be fired on the spot for being an idiot - and rightly so. Too bad the rest of the white collar world isn't like that.
Grouchy Old-fashioned Gen X'r
I'm OK with buzzwords so long as all the stakeholders (see what I did there?) are clear on the shared meaning of each word/phrase.
In general I think that buzzwords are good when used for encapsulating ideas and concepts. it simplifies communication between people who understand the words. However, I draw the line when people use a buzzword when a perfectly normal word would do. I know someone that will say they were "On an Audio" when they mean phone calls or say "dialogging" instead of talking. It makes me want to hit them. Hard!
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.
Our company has been thinking about scrapping our interview procedures and bringing each candidate in for a 4-5 hours sit-down with some of the programmers and just do some pair programming.
I like the idea in theory but I am not sure how you can really make it fair for each candidate. How would you rate them? Wouldn't their input really depend on what each programmer was working on that day?
Any thoughts on whether this is a good idea/bad idea or how to make it work is what I am kind of looking for here.
Cheers!
EDIT:
RESULT - AS requested
We are going to conduct the first steps of the interview the same as before. Phone followed by face to face. Instead of bringing them back for a third and final grilling, we are going to bring 3 developers back to sit with all 7 members of the team. We have decided to let the team decide who is then hired.
We have come to this conclusion for a couple of reasons. We believe this will empower the developers by giving them a choice who they are working. The second reason is group dynamic. We think it is really important to have a good group dynamic and it is hard to tell until after you hire a person if they will fit in or not.
So the end result is we are going to go ahead with the pair programming sessions but in a completely different way and for a completely different way than was originally intended.
Any thoughts or criticism of this approach is more than welcome!!
(this edit is posted as an answer below so feel free to downvote if you feel this is not the best approach)
Unless you use pair programming extensively in your real-world development, I'd be very hesitant to use this. I've met any number of high-quality professional developers who have mentioned a strong aversion to pair programming and whose skill would not be well-judged in such a process.
I hope you have a bunch of steps ahead of this one. For this to work you need an excellent resume and phone screen. You don't want to spend oodles of time on candidates that you shouldn't be talking to in the first place.
So you suggest an initial interview
and possibly have the second interview
as the pair programming session? – Ted
Smith (1 min ago)
Yeah. You might even think of having a simple coding interview happen over the web using something like CoPilot.
The easiest way is to give each person the same programmer to work with and the exact same piece of code.
The problem you're going to run into, is that hiring isn't like programming. There isn't a step by step process to lead to the right answer as to who to hire. (you can have multiple steps to make the decision easier). You have to evaluate each one on their strengths etc. and essentially make an educated guess as to which is the best one to hire. Sometimes you guess wrong.
The other thing about pair programming you're going to have to watch out for is the amount of time necessary to have each candidate at that stage go through that kind of a test. If I were looking for a job, I would be hesitant to go an interview at a company that would ask me to do that. Why? Because that is a lot of time, and if I am interviewing at multiple places, I could spend literally days just going to interviews for jobs I may not even get or want. Someplaces like Google or MS would be an exception, but most places are not like those two. (Not to mention the fact that if they are working on real code, you are essentially asking them to do someone's job for free).
As a personal anecdote, I got smacked around in an interview because of a technique like this. I had gone far in their interview process; passed the resume checks, the code submission and this was the face to face portion of the interview.
I was fresh out of university and had never pair programmed before nor done TDD. They sat me down to do a deck of card exercise and it flopped. Badly! I didn't understand why the interviewer was writing tests that seemed so dumb* (IE "return null;") and they didn't explain why and of course being foreign to TDD I didn't know what questions to ask. The end result was that it looked like I couldn't program my way out of a paper bag.
If you're going to do this type of exercise you need to cater to the interviewee because they're going to be in different spots with their aptitude. This means that you'll get different assessments that may not be based on actual talent and are thus going to be heavily biased.
**Now that I understand TDD, I do understand tests like this and how it's supposed to work, but man did that ever seem stupid at the time!*
I just had an interview with a San Francisco based company that prides itself on Agile methods/etc. I was to interview the CEO himself. I have about 20 years of experience in the industry, but have never pair programmed or developed using TDD approach. I was told it would be a "programming interview" but had not idea what to expect, and before we started the guy said that he thought that I may agree that all interviews should be done this way. (which in retrospect was nothing more than an arrogant statement).
Anyway, at the interview the exercise was to develop a class using TDD. It took me a second to adjust my thinking on the entire process, again since I had never pair programmed or done TDD. While I stumbled here and there I did ok in the end. but his reply was the I did not exhibit the aggressive back-and-forth nature that they require for their pair programming environment. Now, that could also have been an underhanded way of saying that "I didn't think you did great" kind of message.
Luckily I didn't need the job and to be honest the experience made me realize that I'd rather find a different career than having to be a software engineer that HAS to work in pairs, day in day out, when it came to developing code. Odd thing is that on occasion I have worked with another person on code simultaneously, so anything is possible.
In end I guess it was a good outcome since they didn't think I was a good fit and I didn't care for their working methods. But we would have came to the same conclusion had I talked a for a few minutes more about myself and had he given me a little more info on how they go about their work. Which is to say that there are other ways of finding a good fit candidate than putting them through the stress of pair programming with a complete stranger; bogus way to gauge competency imo.
One particular company uses a technique called extreme interviewing. For the extreme interview they will bring in say 30 developers and group them into 15 pairs. They will explain that they are looking for people who work well with others. That they will make a hiring decision based solely on their ability to work with others.
They will provide a problem for the pairs to solve. They will emphasis that they are not interested in the solution just each programmers ability to work with others. For each pair they will provide an observer of the pair. During the exercise (about 2 to 4 hours in duration), the observer will takes notes about a person ability to pair ... not the solution.
They are amazed how many programmers focus on solving the problem instead of collaborating. Of the 15 pairs, they will identify about 4 to 6 developers for a second interview. Those developers will be asked to come back and spend a week with the team (they get paid). After a week, they decide who to keep. Generally about half of them (2 to 3 developers).
When they are done, they have developers that are able to collaborate and after a week working with various pairs, the team has a strong indication who can effectively develop software. The process is both innovative and effective. They have had a high success rate with those they have hired.
I just had a pair programming interview a few days ago and to be honest, I don't really like it. I was notified of this a day just before the interview and then the interviewer told me that pair programming is what eventually I am going to do anyway in work. I went into the office and was paired up with someone who is a very senior software engineer. The company is in San Francisco and they are a well renowned company for pair programming, everyone pair programs in the office. At first it seemed to be fine, he explained about all the tools they used, their own unit testing framework that they build, and a bit of the project. He then basically wrote a bunch of unit tests and wanted me to work on the implementation to make it pass. Just as an FYI, the code base that already exists is huge, I would say 10k lines, it's not like a super complex project, but it is complex for someone to just step in and then write code without prior understanding of the class hierarchy etc. I find it really hard to believe that he expects someone to jump right away in a 10k line of source code that already exists. It just doesn't match for a pair programming interview, a smaller code base would help. I struggled a bit from navigating through the classes and going back and forth because I can't remember class names as I was overwhelmed by the amount of classes/code that already exists. To be honest, this really made me do horrible in the interview process. In the end I didn't feel really good about it. I haven't done pair programming before, mostly is just during assignments in my college year.
To me the power of pair programming can be harnessed if you're already proficient/comfortable with your pair, but is not really suitable for interview. Sometimes I would like to ask questions to my pair, but then I thought if I ask too much questions, then they would assume I were stupid and can't perform. If this was already on a real job, I wouldn't hesitate to ask, but in an interview it's hard.. you want to ask because your pair should help you out when you're stuck, but at the same time it's an interview, so you can't really ask much.
That is just my experience that I have from pair programming interview, my suggestion if you really want to do this:
be sure that you don't give the candidate to work with a large code base, work with a
smaller one and therefore he/she can show his/her skills to the max
be up front with the candidate before pair programming interview, can you ask questions
when you're stuck, should you be able to do this and that, what can't you do
be as detailed as possible
In the end, I wouldn't suggest it. It's hard to measure a candidate's performance in pair programming, and it might be biased as well.
I like this idea. However I think it might be difficult to do since it would require the candidate to have some knowledge of the project you would pair on with him. Also, 4 to 5 hours seems a bit long. What if you immediately see that it is not going to work out, are you going to sit through the whole session with the candidate?
Good question though. Stuff to think about.
Why not? Also, it's not like interviews are always (or ever) fair. You should evaluate the end results of the new approach against the traditional interview-based approach.
Also, a mini interview before the pair programming session might be good to keep from wasting the programmers' time with people who would be a bad fit.
From my limited experience, my feelings are mixed. I like the idea of pairing as part of an interview, esp. if the company uses pairing often, because it gives both a better feel for the fit. As a candidate, I've often gone through interviews where I sat in a room answering questions for a few hours, but afterward didn't have a good feel for what it would really be like to work in their environment. Pairing may be more beneficial than a random coding exercise, unless the interviewer is skilled at working someone through those. And I like being able to discuss technical stuff from both sides. And as a candidate, I'd rather interact with someone than just answer questions or solve code problems on my own.
But... as others have noted, the time needed can be an issue. I've gone through a couple days of pairing interviews and found some periods good, while others felt like a few hours were wasted: one because the developer wasn't working on something that lent itself to pairing (esp. given my background), the other because an env issue prevented much useful work for a while. If the job doesn't work out, it can be frustrating to have taken a day or two off work for this.
One place trying this approach wasn't sure if they should have someone outside the company working on a customer's project. They also worried that explaining the domain and work being done would take too long, though without that the candidate may not be able to contribute much. So they chose an open source project the employee was working on.
This seems to be a key point: there needs to be a well chosen task that the candidate can understand quickly and be able to contribute to. The latter part will depend somewhat on the candidate's skills. Also key would be the employee's ability to evaluate someone with this approach. Not everyone is great at normal interviewing, and that's probably more true of a pairing interview.
Also, if a company doesn't do much pairing then this kind of interview may not be as useful. There does seem benefit in seeing someone code (as Joel Spolsky notes), and this could be a good way to do that. But if pairing is not a typical part of the job, then perhaps a full pairing session isn't appropriate. Maybe a modified version.
I'd be curious what companies who have taken this approach think of the results. Reading some of the other answers to this question shows that it doesn't always seem ideal from the candidate's view.
To keep it fair, you'd have to make every participating staff member have a prepared problem to evaluate the candidate on. Preferably something taken form the real world in their company experience, but something that has already been resolved. This is a good chance to evaluate the knowledge on a problem and evaluate not just programming skills.
I hate it when too specific questions are answered. I had an interview once where a programmer was testing my knowledge of the STL which I used extensively and was trying to get me to answer that a custom allocator was needed. I had heard of them but never used them (esp in windows) and was made to feel dumb. IOW, avoid being judgmental.
So my point is, ask practical questions that aren't so much about testing programming knowledge as you can evaluate more qualitative personality and problem-solving approaches if you use the "pair programming" idea.
Good question!
Honestly, that sounds like a great idea, though Jason Punyon is certainly right that you should do a lot of weeding before you waste significant amounts of your developers' time on culls. You get a glimpse at an important metric out of it that's otherwise nearly unobtainable in interviewing: what someone's like to work with.
I don't think there's really any need to be concerned about it being "fair" based on the subject matter or trying to present consistent situations to different candidates, if you maintain the right evaluatory attitude -- that it isn't about whether they "got the right answer" or jumped through the right set of hoops, but what sort of effort, problem-solving, communication aptitude and flexibility they showed. You'd lose most of the benefit of the exercise by turning it into an artificial test, not to mention changing it from something that your developers can get some benefit from (or at least still get some work done during) to a massive waste of their time.
Joel Spolsky has an excellent Guerrilla Guide to Interviewing which talks about, amongst other things, programming tasks.
Trivia: Joel Spolsky is a co-founder of stackoverflow.com