The Right Way
What is the right way to architect or develop or implement software? You’ll probably have as many answers as the number of professionals you ask. In fact, I know my answer constantly changes with my experience and the situation. So, should we seek “The Right Way?” If so, what are the questions we must ask ourselves if we are going to find “The Right Way” for our project?
It has been my experience that the questions are often more important than the answers, and knowing which questions to ask is the key to the maturity of a software design.
Sometimes it helps if your organization already has one or more frameworks on which you must build. That reduces the number of questions needing to be solved. If you are already an Oracle shop using Oracle tools, and that is the company mandate, then your questions fall within the framework of the capabilities of Oracle.
The same goes with software development techniques. For example, do you need to design with Dependency Injection on all your projects in order to enable unit testing with Mocks; or, can you instead use a tool such as TypeMock which works even without using an injection pattern? TypeMock even has a forum thread asking this same question
If you are still tracking with me as I ramble a little here, you could ask the question, if you always need to design with interfaces, or use enterprise development patterns? I submit that this is not the correct questions. Instead you may ask, what is the purpose, lifecycle, probability of extension of software in order to determine if it really requires enterprise techinques.
On the other hand, when you use good software patterns all the time they become easy to write and easy for your team to follow, because they tend to be similar in most implementations. Recently I came across a solution using the MVC (Model/View/Controller) pattern which had no user presentation in either a web page or screen. Still, because the MVC pattern is common it was easy to follow how the program was laid out, and what it was intended to accomplish with little orientation.
So, I leave it to you. What is the Right Way, and how do you get there? Join the conversation with your comments, or drop an email to btaylor@sswug.org.
Pair Programming Reader Feedback
Javier writes:
Here is my 1% on this subject:
1) Some companies hate employees performing pair programming (still in 2013). It is mainly because they have never tried it, so they do not understand it and just fear it blindly.
Other reasons might be that in other departments (Accounting, Financing, HR, etc.) this is not known at all and might produce reactions over IT Dev.
Most software companies (those that produce software as the end product) do not have any problem with this at all.
2) Doing PP produces all the benefits that you mention on your article (paragraphs "When two developers work on " and "Pairing provides a great…. "), so I won’t repeat myself here.
3) I have found that not only does PP help in writing better code (clean, well thought of, properly refactored, solid, etc.), but it also helps a lot in our day to day mood at work (being inside a company for 7-8h).
We feel simply so much better, more motivated, and we even have fun. I find that writing code as a lone ranger is boring as hell (but also pays the bills).
Some people enjoy sharing a bit of their personal life (I do this all the time), so you end up not only working better with someone on a daily basis (or as long as the project lasts), but also knowing a person, and you develop a good relationship of trust which can endure companies (rotation in IT is pretty high).
You gain trust, and trus is also needed when things go totally wrong: production bugs, tight or ridiculous deadlines, the less and less frequent "overtime", "touchy" meetings when everyone is on the edge defending themselves, etc.
I feel that when you share all your knowledge with someone, especially more junior developers and you show them the internals of the GC via code profiling, or deleting hundreds of lines of code to introduce some design pattern(s), it feels so much better. The gratification factor is excellent and cannot compare with the thoughts of some random project manager that finds the technique unproductive because he read it on some book 🙂 People are people and do not behave as machines, so the social factor plays a huge role in productivity as well.
Cheers,
Ben