Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I have a problem when designing any application that is either greenfield or a refactored brownfield due to often finding a potential flaw or an uncertainty with the design or architecture that I think up. I waste a lot of time trying to construct a design that I am confident in without a lot of time invested from the beginning. I feel that mistakes early on lead to big issues later in development (especially when refactoring brownfield apps).

I want to minimize this, but am unsure how to do it without an optimal solution or bothering the senior devs or the architect. For example, there is a legacy application that needs to be refactored. I can rewrite it in a new project and reduce the lines of code from 12k to 2-3k. The application's purpose is to generate HTML pages, but is done in a console application in C#. I have not done any web development until now, but I am unsure if ASP.NET MVC would be a good choice, and even if so, if my design or architecture is a good choice.

I understand when working in a team I can receive good and solid advice, but how do I become less reliant on my team's thinking and more on my own without wasting the company's time researching every technological possibility? Does this just come with time and experience? If trial and error is the true and tried way, can architecture and design really be done in an agile way with minimal time wasted?

share|improve this question

closed as too broad by gnat, MichaelT, GlenH7, Dynamic, david.pfx May 18 '14 at 10:56

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

What does Agile have to do with your question specifically? – Robert Harvey May 16 '14 at 17:25

1 Answer 1

up vote 1 down vote accepted

Agile methods generally start and end with the customer. The customer may be internal to your company or an external consumer. Either way you need to understand their requirements and you achieve that through conversation - talk to them, discus your solutions with them, listen to their feedback and suggestions. This all indicates that getting feedback from your team and the users of your software is, rather than being a waste of their time, an indispensable investment of their time; not only in the quality of the software itself, but also in your value as a team member. If your managers and senior engineers are half-decent and familiar with Agile paradigms they will appreciate this, otherwise you have an opportunity to improve the company culture.

The architecture of the system will often be heavily dependant on the IT infrastructure in which your software has to operate: ASP .NET is not the best choice if the target webserver is running Linux. If it's Windows then ASP .NET is great and MVVM (rather than MVC) is a good way to structure your application and assemblies. This means that the architecture choice shouldn't take more than a few minutes to decide!

The design of your solution is the bit that takes the time and experience, and this is where Agile methodologies really do help, because they effectively allow you to improve your design as you go along. Do one little bit at a time, make it work, get feedback from the customer and move on to the next bit, refactoring what you did before if you need to. The 'design' is what you end up with, rather than what you start with. Providing you test thoroughly at every stage and incorporate your customer feedback as you go along, what you end up with will work and if it works then it is a good design. "Only just good enough is good enough." Of course, you do have to consider the 'habitability' and maintainability of the source code.

Test Driven Development is a popular way of managing both the functionality and quality of the code you produce. It's particularly well suited to Pair Programming, but is easy to use when you have to work alone. This is certainly a technique that I would strongly recommend, even if you don't use anything else from the Agile portfolio. When combined with MCDC test coverage you can get a very high confidence level in your software.

Implementing your selected architecture effectively does require trial and error (and research, SO, coffee, cussing, late nights, etc.) but even experienced developers still spend their time going through that. Good development practices help you get to your goal quicker and the whole point of Agile is that it is a collection of "better ways of developing software".

So, to answer your question: stop worrying and start coding (and have fun!) :-)

share|improve this answer

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