Programming in different directions...
-
I did a few weeks back, I was not taken seriously... Now that we started coding and I can show them the benefits of good design in practice they start to listen. Except now it is too late. They want that form finished a.s.a.p. :)
It's an OO world.
unfortunately that's the business world... they want everything done yesterday... :laugh:
-
Well... Actually I should explain the core of the problem. My boss has always been the 'senior' programmer at our company. It is a small company, so it is not that hard. I started programming there about 8 months ago now, without any prior programming experience (well, some scripting here and there). Without wanting to be cocky I can say that in those 8 months I have surpassed all the programmers at the company (at least as far as OO(D) thinking goes). So let's just say that in the land of the blind the one-eye is king (I consider myself one-eyed ;P ). How would you feel as senior programmer if a rookie like me went telling you what to do and how to do it? There is no way in hell I am going to write the underlying framework. And on top of that my other employers (I have 3 total) are afraid I will write code that no one understands and then go work at another company leaving them with software they do not understand (it has happened before at our company). Today was my day off, but I actually send a mail to my employer (the one that ruined my interfaces) telling him I did not like his 'solution' and that the exact same could actually have been achieved by my previous method without having all those extra methods you do not need and without excluding other solutions as well. He send me a mail back telling me that at least now he could omit 'alien code such as:'
' The 'bridge' is actually an adapter, the SomeEntity is the bridge...
' My boss has read about databridges though and wants to stick to that naming, simply because he 'wants to see that name'...
' SomeEntity Implements Interfaces(Of T1, T2) which should match the bridge's T1 and T2.
Dim bridge As New DataBridge(Of T1, T2)(New SomeEntity, connString)So you see the problem :D
It's an OO world.
truth is... the boss makes the decisions, whether good or bad, all you can do is make recommendations... he has to live with the consequences in the long run (although you may too)
-
I would suggest you sit down with your boss and start defining the architecture of the system before you do any more coding. Unless you are both working on the same page, your app will end up a disaster.
I work in a very RAD environment and can vouch for the need to properly architect a project. Unfortunately for me, everything needs done the day before yesterday and the time is never taken plan out a project.
-
Thanks for the concern. I did make those interfaces because we needed them. The problem is that my boss does not find interfaces easier... He is all into base classes. So instead of using multiple interfaces he could implement or not (which was what I had made) he now made one base class with a dozen overridable methods X| We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
It's an OO world.
Oh boy, why don't you tell him to write the whole application in a single class. Define Forms as internal classes, make all variables static/global and insert a global self-destruct button.
-
Fix the team issues first. Second:
Naerling wrote:
I want to make flexible and reusable software
Many horrible systems have been born from that statement. I've created a few myself. Don't write a single line of code for changes that aren't needed right now. Stick with simple objects and only add interfaces if the class needs it to make the code simpler and easier to understand.
Curvature of the Mind now with 3D
I couldn't agree more. But that depends. I've seen projects go downhill because all the unnecessary super uber architecture prevented the project from finishing on time. One of them has been there for 3 years and it's not finished. It should've taken over one year and it was planned to finish in 8 months. On the other hand, critical systems (take real-time banking systems for example), that have continuous evolution and scalability should have a very solid design from start. I haven't gotten there yet, but I always try to prepared myself for that when the day comes.
-
I couldn't agree more. But that depends. I've seen projects go downhill because all the unnecessary super uber architecture prevented the project from finishing on time. One of them has been there for 3 years and it's not finished. It should've taken over one year and it was planned to finish in 8 months. On the other hand, critical systems (take real-time banking systems for example), that have continuous evolution and scalability should have a very solid design from start. I haven't gotten there yet, but I always try to prepared myself for that when the day comes.
I think the same prinicples still apply. Start simple and add as little as possible each time you put the system into production. I've done high performance web services that are literally hammered with thosands of requests 24/7 with live updates to the servers, and having a flexable simple design was even more critical. Complicated systems are way to hard to troubleshoot when you run into an issue.
Curvature of the Mind now with 3D
-
I think the same prinicples still apply. Start simple and add as little as possible each time you put the system into production. I've done high performance web services that are literally hammered with thosands of requests 24/7 with live updates to the servers, and having a flexable simple design was even more critical. Complicated systems are way to hard to troubleshoot when you run into an issue.
Curvature of the Mind now with 3D
I agree with that, but to scale things that do not have a good design from start is very difficult. I don't mean create incredible design, just very flexible design that can be simple. This adds a little overhead of time, but it's worth it. On the worse case scenario, imagine a flat unlayered web site with no Entity classes defined. I've seen that, too simple and too bad. I had to scale it and it was very difficult. I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there.
-
I agree with that, but to scale things that do not have a good design from start is very difficult. I don't mean create incredible design, just very flexible design that can be simple. This adds a little overhead of time, but it's worth it. On the worse case scenario, imagine a flat unlayered web site with no Entity classes defined. I've seen that, too simple and too bad. I had to scale it and it was very difficult. I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there.
"I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there." Exactly. I've always found that I've attained that needed balance when I've gotten the behavior allocation correct, which takes thought. When correct, refactoring isn't too bad because it can be done without ripple effects throughout the rest of the code. That allows the design to be "simple" at first yet be easily refactored to fit future needs. By that metric, both designs are bad -- one has extra complexity that clearly isn't needed, the other is too simplistic in its behavior allocation to be easily refactored in the future.
patbob
-
"I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there." Exactly. I've always found that I've attained that needed balance when I've gotten the behavior allocation correct, which takes thought. When correct, refactoring isn't too bad because it can be done without ripple effects throughout the rest of the code. That allows the design to be "simple" at first yet be easily refactored to fit future needs. By that metric, both designs are bad -- one has extra complexity that clearly isn't needed, the other is too simplistic in its behavior allocation to be easily refactored in the future.
patbob
That's exactly the idea I support.
-
Fix the team issues first. Second:
Naerling wrote:
I want to make flexible and reusable software
Many horrible systems have been born from that statement. I've created a few myself. Don't write a single line of code for changes that aren't needed right now. Stick with simple objects and only add interfaces if the class needs it to make the code simpler and easier to understand.
Curvature of the Mind now with 3D
Exactly. Create the ability to reuse code once you have the need by refactoring.
-
Thanks for the concern. I did make those interfaces because we needed them. The problem is that my boss does not find interfaces easier... He is all into base classes. So instead of using multiple interfaces he could implement or not (which was what I had made) he now made one base class with a dozen overridable methods X| We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
It's an OO world.
Naerling wrote:
We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
As described however that is not OO programming. And worst case it is an anti-pattern. http://en.wikipedia.org/wiki/God_object[^]
-
Naerling wrote:
We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
As described however that is not OO programming. And worst case it is an anti-pattern. http://en.wikipedia.org/wiki/God_object[^]
Actually, my boss said the same thing last week... Our current application has a Class that does just about anything. My boss identified it as an anti-pattern and a God Object. I guess he did not learn from it :( I am currently on a bit of a quest to learn all about architecture. Those anti-patterns are interesting. Knowing what NOT to do is at least as important as knowing what TO do :thumbsup:
It's an OO world.
-
Thanks for the concern. I did make those interfaces because we needed them. The problem is that my boss does not find interfaces easier... He is all into base classes. So instead of using multiple interfaces he could implement or not (which was what I had made) he now made one base class with a dozen overridable methods X| We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
It's an OO world.
Naerling wrote:
We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
:doh: He's obviously never studied/understood OOP principles! You DO NOT have a single class that does everything; that's basic OOP.
I'm too lazy to Google it for you.
-
I agree with that, but to scale things that do not have a good design from start is very difficult. I don't mean create incredible design, just very flexible design that can be simple. This adds a little overhead of time, but it's worth it. On the worse case scenario, imagine a flat unlayered web site with no Entity classes defined. I've seen that, too simple and too bad. I had to scale it and it was very difficult. I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there.
Fabio Franco wrote:
On the worse case scenario, imagine a flat unlayered web site with no Entity classes defined. I've seen that, too simple and too bad. I had to scale it and it was very difficult.
The site I was talking about I had to use bulk loading on a separate thread and spawned 4-5 threads at startup using data readers with ordinal access for performance. The database used tables partitioned on the hour, and used hand coded serialization code to cache results in memcached. All the ORM tools were way to high level for the project. When you have 10 Gigs of hashtables for lookups, managing everything down to the level of choosing structs vs. classes is important. Moving from a more enterprisy layered design to something simpler allowed me to change implementations much more quickly and tune algorithms continuously to match each dataset.
Curvature of the Mind now with 3D
-
Actually, my boss said the same thing last week... Our current application has a Class that does just about anything. My boss identified it as an anti-pattern and a God Object. I guess he did not learn from it :( I am currently on a bit of a quest to learn all about architecture. Those anti-patterns are interesting. Knowing what NOT to do is at least as important as knowing what TO do :thumbsup:
It's an OO world.
Naerling wrote:
Our current application has a Class that does just about anything. My boss identified it as an anti-pattern and a God Object. I guess he did not learn from it
lol. But at least it gives you the opportunity. My opportunity came with a C++ class, one single class, that had over 200 data members, over 200 methods, over 20,000 lines of code and spanned at least 3 source files (not including the .h file.)
