6

I am fairly new in product development and I am trying to work over a product. The problem that I have realized is that people draw diagrams and charts showing different modules and layers.

But as I am working alone (I am my own team) I got a bit confused about the interaction I am facing in the development within the programs and I am wondering whether developing a product in modules is real or not?

Maybe I am not a great programmer, but I see no boundaries when data start to travel from frontend to backend.

gnat
  • 21,442
  • 29
  • 112
  • 288
Aura
  • 205
  • 1
  • 5
  • If you writing code in .NET C#/VB then I strongly advise to teach yourself to use classes, object (and even look at MVC) and replicate similar in Data layers etc. – Piotr Kula Oct 17 '13 at 12:17
  • @ppumkin I am using object oriented language (java) and I have read about MVC. Having said that I WAS a bit confused when I see the creation of objects and data transferring in them from servlets to model classes and from model classes to the databases and then retrieval of data from different points. . . layers seems to be really an abstraction of model what I designed. – Aura Oct 17 '13 at 12:33
  • Yea JAVA is a bit different though, there is no pressure on creating layers because its fairly simple to access data using existing libraries. JAVA is also very isolated and leans towards interfaces. End of the day you are your own project manager, when you work for another project manager they will tell you how it needs to be structured. At all the places I worked each PM had their own best practise.. most of them were very bad though but I worked and got paid. If you find reading your own code easy that is good.. but what if somebody else needs to read it later? – Piotr Kula Oct 17 '13 at 12:37
  • @ppumkin I believe at the end of the day I found a good answer to a confusion :) – Aura Oct 17 '13 at 12:56

2 Answers2

22

The "layers" that we describe when we describe software systems are abstract concepts. To the computer, all it gets to see is a featureless stream of one opcode after another, no matter which layer, which class or which method it originally came from. In this sense, they are not "real" at all.

However, layers (and classes and methods) are useful for programmers to ease thinking about the system. By voluntarily restricting ourselves to think about the system only on one level of description at a time, and to think about an operation only in terms of its input and output rather than its internal workings, we increase our ability to understand the relevant parts when adding functionality or making a change.

This is initially quite counter-intuitive, and under-taught in formal education. But I assure you that judicious use of abstraction is the only thing that makes software development "in the large" possible at all for people who aren't autistic savants.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • Thanks @Kilian a bit harsh at last but helped me a lot :) – Aura Oct 17 '13 at 12:00
  • 1
    I always find layers to be confusing vs. thinking of a whole working system. It feels wrong :) Black boxes are more tangible and logical. Layering feels like slicing a part of a car and hoping to understand how the whole car moves, just by looking at a very small part of it. But anything that helps a person to understand is bound to be good :) – Juha Untinen Oct 17 '13 at 12:38
  • Its wonderful how you get 12 upvotes in 37 minutes... vs 3 on the OP. one of which is mine. How do you do it? Especially the ratio of 89 visits. – Piotr Kula Oct 17 '13 at 12:59
  • @ppumkin you may wish to glance at [Why always answers of users who have the maximum reputation in a question accepted and voted up?](http://meta.programmers.stackexchange.com/questions/5868/why-always-answers-of-users-who-have-the-maximum-reputation-in-a-question-accept) from the meta site. –  Oct 17 '13 at 14:15
  • 2
    maybe cause it's a really good answer? – naftalimich Oct 17 '13 at 14:18
  • 2
    Presumably 14 people (at the time of writing) did think it was that great an answer - if you disagree, you are of course welcome to downvote it and/or post a better answer. – Useless Oct 17 '13 at 14:59
2

Adding my two cents...

You’re your own team; you’re working alone on that product, one piece of advice: keep it simple, stupid!

In your case, I don’t think you need to abstract things creating layers or modules, you’ll only gain complexity.

Things would obviously not be the same if you were to work within a 10 guy’s team where some of them would be involved on business rules development and the other ones on the UI. In that situation, separating concerns might be a good idea. Just start simple and write unit tests to protect you from regression.

Why would you have to get things more complicated than they need to? You might not gonna need it at all!

MaxSC
  • 444
  • 3
  • 9
  • 2
    That's not true IMO. I've seen simple programs (5 Java classes), which were a pain in the ass to maintain, because it was configuration, DB-access, webservice-call, business-logic and batch processing all in one (without any layering or abstraction). It took me 2 days to refactor that mess. – Andy Oct 17 '13 at 15:28
  • Well, that's why I spoke about at least putting in place some unit testing. No layer doesn't necessarily means crappy code ;-) – MaxSC Oct 17 '13 at 15:35
  • 1
    While KISS principle is undoubtfully useful, YAGNI should be applied with caution, because looking a little bit ahead never hurts. – Roman Susi Oct 17 '13 at 16:48
  • 1
    -1: YAGNI is for determining whether to include a feature, but good architecture is always useful. You end up writing more lines of code, but they're all much easier to maintain, even for a small project. – Kevin Oct 17 '13 at 18:38
  • Hey guys, don't get me wrong. My own programs have layers and I know that, as @RomanSusi said _"looking a little bit ahead never hurts"_. But in this particular case, `Aura` seems alone. Everyone might find this [article](http://raganwald.com/2013/10/08/defactoring.html) interesting: "_increased flexibility does mean that the code says far less about how it’s intended to work. Whenever you’re reading a piece of it, you are thinking, “it might do this, it might do that_" – MaxSC Oct 18 '13 at 08:08