Do you follow a waterfall process or agile?
Do you use TDD or BDD or maybe D3?
How about SOLID principles? DRY?
I hope that you are aware of KISS and “You ain’t gonna need it“.
Do you plan to expose RESTful or SOAP web services?
What language and frameworks do you use?
How do you structure code, branch it, build your project?
How do you design, review code, comment code?
I can keep going like that for hours… There is unbelievable amount of HIGH level decisions which are made for each project. A lot of them have they own dependencies on other principles and decisions. And all of them will stir the development one way or another and presumably can make a huge difference.
And now the final and most important question. How do you know that your (or your team/company) choice is good and competitive?
I understand that there is no rational way to measure that. However, “It worked for me on last project” sounds like a weak argument.
If the team (or at least some part of it capable of passing on their knowledge) has successful experience with technique X and understands it – most probably adopting X would be beneficial to the project. Exceptions are possible of course (while having hammer in hands, every problem appears to be a nail), but at least you would not throw yourself in experiments without clear vision of result.
People matters, not technologies. As always 🙂
People matter for sure. However, technologies matter too.
If you will take two teams with similar smartness, attitude, experience and they will choose different technologies they may get quite different result at the end.
And this brings back the question – what is the best way to choose methodologies/principles/technologies?
and it brings us back to people. A team will be successful in short/mid term when there’re passionate about some technology people.
exaggeration: passionate ASM dev will be more successful than average PHP in web app
real example: FB — who would thought that for successful web app they should think of mixing C++ and PHP.
>exaggeration: passionate ASM dev will be more successful than average PHP in web app
nope. they won’t.
it will take 5 minutes to write simple blog on ruby on rails and it will take huge amount of time to write it in ASM.
>FB — who would thought that for successful web app they should think of mixing C++ and PHP.
They did it because they had performance/scaling problem and not for the reason that they were so passionate about C++.
that’s why it’s exaggeration
sorry, i might have put it a bit sideways, they are passionate about technology and that’s why were able to get out of php box into mixture of c++, and they definitely have people passionate about C++
I haven’t seen any (successfull) project following clear set of methodologies. It just doesn’t work, but rules of each methodology form set of best practices and thus create a project-specific methodology.
If you get requirements from a customer – waterfall will not work, blindly following TDD in research or prototyping project just will eat time on rewriting tests. And so on.
I agree that blindly following some methodology doesn’t work.
Let’s go back to the last question : “How do you know that your (or your team/company) choice is good and competitive?”?
As example, it’s not obvious how much design you should do upfront? Does it make sense to do BDD or TDD or some mix of them?
TDD (aside from covering code with tests) is definitely useful because you’re acting as first user of API in question. And that helps revealing usability problems of your code early, when you can afford redesign yet.
As for the question. I doubt that some decent criteria exists, it would be just too easy. I’m not sure how to measure competitiveness and quality at company’s level, but from software engineer position when I look at some piece of code and try to use it – it feels right. Or doesn’t feel right.
That’s kind of the heart of the problem
a) We have just a feeling whether something right or wrong and we have very little real data or evidence.
b) Our feeling relates to some super small activity (as example “reading the code”) and in no shape or form it relates to the overall company success.
Based on this, there is quite good chance that something what we believe is right actually hurting the business.
a) well, we do have real data when comparing experience of working on quality codebase and crappy one. Cost of simple change varies from several minutes to several weak or even months sometimes. That’s something most of developers can clearly see and absolutely every company could feel when moving release dates or extending budgets.
b) I’d not call reading/writing code “super small activity”, at least in the software engineering field.
In general I agree that problem exists, but can’t help here much – my interests are limited with architecture questions, at least for now.
I was an architect on my last job and at that moment it was kind of straightforward. I had two concerns:
a) To follow existing culture (high quality code, up front design and later agile development)
b) To make me happy (don’t write “crappy code” and don’t fix old bugs in this code)
Now, it’s kind of different, because I am more involved in business side and I am trying to connect the dots between methodologies and bottom line of the company.
How do you know that your (or your team/company) choice is good and competitive?
Go and and ask your team, people from other teams, local communities, blogs, etc. And then have talks within the team/company. There always will be some trade-offs.
It’s back to the question how many passionate and high quality experienced people you have and trust. As you said it’s your team/company choice (which doesn’t mean that you can’t influence it should you disagree). Honestly, looking forward to your posts on this!
You know your choice is good/bad based on results. Anyone who has been a developer for a while probably has experience with many different styles and does not stick with just one.
Another aspect of this is the leadership model. Are you a benevolent dictator or do you head a committee. At the stage of development before you can measure the results I think the management style is more important than the methodology. As Ivan said, people matter. Leadership can make the difference between adoption of a methodology or chaos.
>You know your choice is good/bad based on results.
I would like it to be simple like that 🙂
Good results shows only that some set of variables led to good results. It could be smart people, good market, methodology or most likely some mix of them.
I will write separate article regarding correlation, causation and coincidence.
Sure, it’s not really possible to pull it apart and determine the exact causes of success. That limits everything in this thread. There is a need in this industry to be practical. Methodologies allow people to work in coordination. This framework is required for most significant development efforts. However, I think the selection of people and the direction given the team are more important than the chosen methodology. Particularly with a new team and an unproven track record. There is as much art as science in what we do.
I agree on all points here.
The only issue is when you are part of the team and you try to argue for one set of principle vs another.
Do you remember we discussed multiple times that it would be better to develop simpler code and to decrease level of indirections? The problem which I see that it’s only a feeling that it will make overall development effort smaller.
So, yeah… it’s as much art as science.