Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Looking for ways to switch team/individual culture from chasing latest fads, patterns, and all kinds of best practices to focusing on finding quickest and simplest solutions and shipping features.

My definition of "tech fetish": Chasing latest fads, applying new technologies and best practices without considering product/project impact, focusing on micro optimization, creating platforms and frameworks instead of finding simple and quick ways to ship product features.

Few examples of culture differences:

  1. From "Spent a day on trying to map database query with five complex joins in NHibernate" to "Wrote a SQL query and used DataReader to pull data in"

  2. From "Wrote super-fast JSON parser in C++" to "Used Python to parse JSON response and call C++ code"

  3. From "Let's use WCF because it supports all possible communication standards" to "REST is simple text-based format, let's stick with it and use simple HTTP handlers"

share|improve this question

closed as not a real question by Wyatt Barnett, Tom Squires, gnat, Jarrod Roberson, Walter Apr 2 '12 at 23:08

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

4  
Is there a question here? –  Wyatt Barnett Apr 2 '12 at 15:28
6  
@WyattBarnett: I think the question could be put more simply as "How can our team stop getting distracted by all the shiny new tech and focus on getting done that which needs to get done, as simply as possible?" (OP can correct me if I'm wrong). –  FrustratedWithFormsDesigner Apr 2 '12 at 15:31
2  
some of your examples are all over the map, fighting an ORM isn't the same as not using WCF. –  Ryathal Apr 2 '12 at 15:32
1  
@FrustratedWithFormsDesigner: that is what I think here too, but I'm trying to avoid putting words in people's mouths . . . –  Wyatt Barnett Apr 2 '12 at 15:32
2  
The question is about developing focus on simplicity and "good enough". In this context all examples are relevant. –  Serge Apr 2 '12 at 16:57
show 1 more comment

5 Answers 5

You need to find the right balance.

What is the focus? Is it fast release cycle, future of the system be-damned?

The future of the system is very important. So is the right tech, architecture etc, but if you don't hit your market then a product may fail. Explain this to the techs.

Techies like to learn and play with new things and allowing them to innovate and experiment is important, but not at the expense of the business.

As horrible as it might sound, your team needs more management or rather appropriate team leading.

If someone on your team spends a day wrestling with an NHibernate query which could be done in 10 mins as a normal SQL query when you have a deadline, then yes, there is a problem.

share|improve this answer
    
Focus in on keeping systems simple and avoiding unproven technologies and practices. Simple systems are easier to modify and support. –  Serge Apr 2 '12 at 17:01
    
@Serge - Only if you have a pressing business need. New tech needs to be played with and tested, but only when the time is right. –  Ozz Apr 3 '12 at 8:32
add comment

One possibility is your team inexperienced so they aren't aware of what the simplest solution is and so they are programming by trial-and-error. Maybe they know Python well, but not C++ so they decide to write as much as possible in Python with C++ interops, which may not be the best solution but suits their skill set. In this case you need an experienced programmer who can take lead and help them find the right approach to take.

Another possibility is your team is not committed to getting things done because they find the solving the problem less interesting than playing around with new technologies. It is good to experiment with technologies to an extent, but if it is over-complicating and slowing down development, then you need a manager to set deadlines and crack the whip so to speak.

share|improve this answer
add comment

Maybe you could introduce a development method in which you can have a fine-grained control over planning and activities of the team. E.g. in SCRUM the team has to

  • Break up the development into small chunks (user stories).
  • Estimate the time needed to implement each user story and commit to it.
  • Report daily about progress, activities, problems, and so on.

In this way each team member

  1. has to motivate their implementation choices (why did they adopt that time-consuming solution if there was a much simpler one?), and
  2. motivate and take responsibilities for any delays (did they focus on implementing and testing the solution, or did they play around too much?).

Once you have established more discipline and focus on the requirements and deadlines, you could also consider giving the team some free time (like 5-10% of the total time) for trying out new technologies (as an activity that is not related to the main project(s)): even though I agree with you that the main focus should be in using well-known techniques to produce a good solution in a reasonable amount of time, sometimes trying out a new technology can bring some benefit. So I would reserve some room for that too, but in a structured way.

share|improve this answer
add comment

As the saying goes, "There's always at least two sides to every story." As is so often the case with questions on this site, this question has me wondering about that other side. Maybe you're dealing with a bunch of undisciplined cowboy coders who need to be reigned in. Or maybe your the sort of person who's become very comfortable with what you know, and therefore uncomfortable with change. From here it's hard to tell. Actually, I bet it's hard to tell from there, too.

The only solution (I can think of) to this quandary is "Show, Don't Tell." Take something that has been solved in a way that you believe is unnecessarily complicated and demonstrate how it can be solved in a simpler and better way. Of course 'better' is very subjective, but if you could demonstrate that your version of the solution was more maintainable, more reliable, more concise, etc., I think it'd be hard to counter your argument.

Of course something like this needs to be handled very carefully, otherwise folks are likely to get offended. I think if you can approach this with a very open-minded, non-critical attitude, that will go a long way towards heading off unnecessary conflict.

share|improve this answer
    
Risky, but I like the idea of showing simpler alternatives –  Serge Apr 2 '12 at 20:15
add comment

Hire older developers who are less likely to become infatuated with new technology because they've been-there-done-that already.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.