Real Life Design Methodologies

[sp4ceman]

i said a ****ty but WORKING product is better than nothing.

if you give me the choice of a dev sitting for 3 days analyzing and over analyzing a problem and a dev sitting for 3 days and pushing out something thats messy or smelly code BUT solves the problem i will take the code smell every time. especially if its a relatively small sprint. you can't go terribly wrong in 3 days if you're writing code that actually solves the problem, which means you can always fix it up.

i come from a tdd background and much of what i say is in that mindset. things like code spikes and the notion that you get it working ugly and then refactor are all vested in tdd. when i say ugly code im talking about worrying about things like base classes, inheritance, interfaces, method names, extraction of logic etc. basically just go into zen mode for an hour, write what you can then stop yourself when you reach a milestone or requirement and then clean it up. don't get out of the zone in your logic just to worry about a method name, or if it fits some pattern or whatever. but, make sure cleaning up and refactoring is part of your "coding process" that only you see.

im not advocating shipping this out. its advice meant to stop someone who is worrying so much about architecture, design, patterns, etc that he can't actually begin writing anything. this was the scenario as i understood it that was described in the op

 

[etienne_marais]

Thanks for all the input.

I have questioned my abilities because of all this, but still believe I can be a good programmer if I put shoulder to the wheel.

 

[Hamster]

You, sir, can believe whatever you want :twisted:

 

[etienne_marais]

You, sir, can believe whatever you want :twisted:

Evil !

I am at a stage where I not only want to make it work, but have to

 

[Hamster]

It's simple:
1. Don't be a douchebag
2. Don't be a whiny bitch

 

[CheekyC]

Use established design patterns or create your own patterns built on common behaviour in your app and framework.

Use automated testing always

 

[Kilgore_Trout_Redux]

i said a ****ty but WORKING product is better than nothing.

if you give me the choice of a dev sitting for 3 days analyzing and over analyzing a problem and a dev sitting for 3 days and pushing out something thats messy or smelly code BUT solves the problem i will take the code smell every time.

As someone who has had to maintain code built using this methodology - I hate you.

You are fine building code like a hastily constructed leen to, but when the code base matures and has grown far beyond the initial mandate and maintainence turns into the worlds most complex and sadistic game of jenga you're going to be the person ranting and raving that it takes forever to make small changes and that the software is buggy.

Analysis Paralysis is a bad thing. If you are sitting for three days and don't know how to start it means that you have a gap in your knowledge and need to learn some basic good development practices.

Any monkey can copy/paste code snippets from Stackoverflow. Proper design and development practices are far harder to learn and far more important. In the age of SaaS very few of us have the luxury of tying a bow around something ****ty but working and throwing it out the door. These days we maintain and extend systems for many years and the overhead of designing systems well from the beginning will pay for itself many times over down the line.

 

[sp4ceman]

did you even read the rest. geez dude.

 

[Kilgore_Trout_Redux]

did you even read the rest. geez dude.

You completely contradicted yourself though.

 

[etienne_marais]

Back at a stage where I am analyzing and thinking of repercussions as well as best approaches.

Basically I had a working application using ADO.NET (encapsulated in an API), now I have started to rewrite the application to cater for an existing webservice from a similar application (Silverlight). Catch is it must be able to use either route (ADO.NET OR Webservices). The existing code used custom datastructures specific for the ADO.NET approach. I have decided that it would be cleaner to use the datastructures defined in the webservices for Both ADO.NET and Webservice calls. Obviously now things are breaking as I incorporate the webservice structures which are similar but not exactly the same as the existing structures from when the application was purely ADO.NET.

And you know what, I think its actually better to not rush it and let the repercussions and best approaches come to me before the entire project becomes unmanageable and mangled spaghetti code by forcing myself into a brute force methodology.

 

[CheekyC]

If it is complicated, do a rough POC

I do this a lot. I have 100's of little projects where I try out diff things, app patterns etc.
[/QUOTE]

Keep your classes focused on one task
Split complicated/long pieces of code into smaller focused methods - it will document itself

This FTW. Single Responsibility Principle will keep bug counts waaay down. Guaranteed.

Consistency - coding style, layout, patterns...keep what you are doing consistent

Correct, this then easily refactors into your own patterns & classes that you reuse.

Avoid using too many third party libraries

Hmm depends. Don't reinvent the wheel. Rather use them and abstract if you want to be independent from 3rd party. Rather use a tested 3rd party lib than your writing own, especially UI, etc. If you have your own tried & tested lib, rather use those.

EDIT: And ****ing AVOID inheritance hell. People abuse it. Seal your classes and stop others from ****ing up.

Hmm no don't agree. A well designed class hierarchy is easy to (re)use. Apply Open/Closed principle

[*]The outside-in approach makes you comply with the YAGNI ("You Aint Gonna Need It") principle, so no code is added that you don't need.
[*]Refactoring with DRY ("Don't Repeat Yourself") in mind, will automatically resolve spaghetti code and (mostly) ensure that common functionality is factored out into smaller functional units.
[/LIST]

This also......

I don't agree with doing it messy and iterating. Not because it is a bad approach per se, but because very few developers have the discipline and time to clean up after themselves so you end up with a mess.

My approach is to get an overall idea of the extent of the project, then think of the approach which will result in the cleanest, simplest architecture to get the job done.

Then you implement that. If you find that your understanding of the system's size and conplexity changes (And more often than not it will.) you iterate within the original design to keep the simplest approach to the problem.

Agreed

Bottom line is to think a lot before you code. Identify patterns and build on that. Patterns in UI, services, domain and persistence. Then write abstract classes to implement those patterns. Will save you lots of time later.

I have just completed a pretty large project. Around 400 tables and ~1.5M lines of code.
It is a specialised ERP type app. Only one of it's kind.

When gathering requirements, I did detailed use case analyses and documented in a spec. This was an important step as I was forced to think about what each function meant and how the user would interact with it. Several system and functional requirements required a very careful think about how to implement it. The system has a fine-grained security model where each of the ~3000 buttons is assignable to a permission. Each of the (~350) entities' fields should be Visible&Editable or just Visible or Invisible for a particular permission. E.g floor workers may not see financial fields. Managers may see but not edit financial fields, but account managers can see and edit these fields. You get the picture.

Also, the app needed to be available in any language.

The first step in implementation was to decide on architecture. I my case the client is a Winforms app running in RDP because the app talks to machines, frame grabbers for machine vision, etc. Once I decided on the architecture, I created a UX model. This defined what the app would look like and how users would interact. From this it was easy to extract the UX patterns that the app would provide. This then easily translated into abstract ViewModel (I use MVVM pattern) base classes for the various types of interactions: 'Cards', Lists, etc etc. From there, the services layer patterns also fell into place. I created interfaces to abstract the services layer patterns.

The domain services also utilise a a set of abstract patterns that control the behaviour, validations, etc.

All in all I spent about a year in building and refining an architecture framework that supported the requirements and patterns. This was done by many little late-night mini-projects trying various ideas.
To add a function now, takes literally minutes because of what the base classes provide.

I find that if you just code, you end up chasing down avenues that will often put you in a corner. Just saying I will fix it or refactor later , is a false sense of security because that never happens. Do it properly the first time. It does not take much extra thought beforehand to think up a better implementation. Do a drawing or interaction diagram. Don't just code. Looking at a structural and especially a behavioural diagram gives you amazing perspective.

Bottom line is that I think you should started at the outer layer, the use cases and UX defining the app. This is ultimately what the user will see and evaluate your app against. Then build up from building blocks you put together. Yes I also made quite a few mistakes. Users complaining about this & that. I also used TDD approach and also highly recommend that. Building the test cases took a huge amount of time I did not budget for, but it was a wise investment.

 

[Hamster]

Hmm no don't agree. A well designed class hierarchy is easy to (re)use. Apply Open/Closed principle

You forget that in the real world there are these developers that care more about the deadline and leaving work at exactly 17:00 than they do about the code quality. All your well designed classes stand no chance against these guys.

Seal your classes if they are not meant to be inherited from. You can rather go unseal them if need be.

Composition is a better approach than inheritance most of the time IMO. Yes there are cases where inheritance makes sense but I've seen too many guys inherit just for the sake of adding 12 extra methods to the class. Before you know it (and I have a real life example for you) you have four layers of inheritance calling base functions, overriding some and new'ing others....a complete mess.

The "best" is when they start adding business logic to your entity classes, especially when the person doing it is the "architect" and the excuse is that refactoring is too much work.

No - best advice is to protect the code base all the time from everyone.

 

[CheekyC]

You forget that in the real world there are these developers that care more about the deadline and leaving work at exactly 17:00 than they do about the code quality. All your well designed classes stand no chance against these guys.

Seal your classes if they are not meant to be inherited from. You can rather go unseal them if need be.

Composition is a better approach than inheritance most of the time IMO. Yes there are cases where inheritance makes sense but I've seen too many guys inherit just for the sake of adding 12 extra methods to the class. Before you know it (and I have a real life example for you) you have four layers of inheritance calling base functions, overriding some and new'ing others....a complete mess.

The "best" is when they start adding business logic to your entity classes, especially when the person doing it is the "architect" and the excuse is that refactoring is too much work.

No - best advice is to protect the code base all the time from everyone.

Well yes you clearly live in the real world and have the scars to prove it. Personally I prefer very flat inheritance hierarchies. An (abstract) base with some carefully chosen abstract methods to implement the pattern and then a concrete implementation to provide the specifics. Rarely more levels.

I find that I use the the decorator pattern a lot as opposed to inheritance when implementing business functionality. It allows me to add functionality without touching the existing classes. Composition is then simply daisy-chaining lightweight classes with their own dependencies that implement various aspects of a business 'action' using DI. Works really well and enables one to follow SRP, keeping classes 'pure'.

 

[semaphore]

You forget that in the real world there are these developers that care more about the deadline and leaving work at exactly 17:00 than they do about the code quality. All your well designed classes stand no chance against these guys.

Is it a problem for developers to have lives outside of business hours?

Seal your classes if they are not meant to be inherited from. You can rather go unseal them if need be.

Composition is a better approach than inheritance most of the time IMO. Yes there are cases where inheritance makes sense but I've seen too many guys inherit just for the sake of adding 12 extra methods to the class. Before you know it (and I have a real life example for you) you have four layers of inheritance calling base functions, overriding some and new'ing others....a complete mess.

The "best" is when they start adding business logic to your entity classes, especially when the person doing it is the "architect" and the excuse is that refactoring is too much work.

No - best advice is to protect the code base all the time from everyone.

You're making me scared now

 

[Hamster]

You're making me scared now

 

[Kilgore_Trout_Redux]

You forget that in the real world there are these developers that care more about the deadline and leaving work at exactly 17:00 than they do about the code quality. All your well designed classes stand no chance against these guys.

You have the completely different opinion to me on this.

Deadlines are crucial to a business. Most of the time us developers get to negotiate deadlines so it is just unprofessional to miss them. Often there are a huge chain of dependancies reliant on the estimates we give.

I would also rather work with an 8-5 developer who spends 7-8 hours a day being productive. That guy goes home at 5, spends the evening at gym, with his family, getting in a few hours surfing or chilling with his gf or mates, gets a good night sleep and hits work the next day refreshed and ready to be productive. He lives a healthy life, takes less sick days and doesn't burn out. I would much rather he works with my code.

If you find your team working frequent overtime then there is a problem with management.

 

[Hamster]

When I say "9-5" guy I refer to those that can't even be bothered to show up to a release when their components go live, those that don't bother bettering the code they touch but just add to the mess. I'm not advocating overtime - I did that for four years and I'm over it.

Business deadlines should not affect the quality of the code. You can write off a quick and dirty implementation to technical debt, but then the debt should be prioritized and rectified the next sprint. But that almost never happens.

 

[Kilgore_Trout_Redux]

When I say "9-5" guy I refer to those that can't even be bothered to show up to a release when their components go live, those that don't bother bettering the code they touch but just add to the mess. I'm not advocating overtime - I did that for four years and I'm over it.

Business deadlines should not affect the quality of the code. You can write off a quick and dirty implementation to technical debt, but then the debt should be prioritized and rectified the next sprint. But that almost never happens.

In most places I have worked developers estimate how long a feature will take. We need to estimate at least reasonably accurately and deliver code that does not need to be refactored in a month. If you are a developer introducing technical debt for the next sprint then I definitely don't want to work with you. It is the reason I dislike the "Write crap code and fix it later." approach mentioned at the beginning of the thread.

When business pays you for work done, they should not be expected to keep paying for it for months down the line because it wasn't done properly.

My approach is the old fashioned one of understanding the problem, estimate it to the best of my ability then add 30-50% more time to that estimate for the unexpected then give that figure. You will honestly be surprised at how often that rule of thumb is right and if you deliver a little bit earlier it is always better to over-deliver.

As for pre and post change request testing after hours - too many companies think they can have that time for free so they abuse it. You want to make a habit of taking up my after hours time then you had better pay me for it.

 

[Hamster]

Out of curiosity what type of projects do you work on?

 

[Kilgore_Trout_Redux]

Out of curiosity what type of projects do you work on?

Worked on a lot of different projects over the last 15 years. Probably spent roughly half of them maintaining old systems and half developing new ones. Worked developing for an engineering company specializing in climate science, telecomms, legal, financial and medical systems.

Been around the block you might say.