Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

Writing notes before actual coding?

 
Ranch Hand
Posts: 115
6
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While I have only been coding using Java for 3-1/2 months I find myself getting confused during the process. Trying to translate the next step in my mind to actually typing it in the IDE gets blurry and a lot of times I don't remember what to do next, or I don't know how to get to the next step.  So, what I have started to do is write notes, steps, ideas, whatever I think is the next step I write it down and find that I am having a bit of success with putting the code to the paper. Examples would be like:

1. create class MountainBike extended from Bicycle
2. declare necessary instance variables to be passed as parameter to either constructor or super
3. are any static variables needed
4. each time constructor is called treat it as a bicycle sold and assign an id and counter
5. create methods needed to return data, or print data with regard to the state and/or behavior of mountainBike, such as its cadence, speed, braking, etc
6. overload printDescription method from super and print specific info related to state and behavior of mountainBike
7. objective is to print a summary of the mountainBike's state and behavior


Each topic above may include individual bullet points like where I might include an if statement or while loop is included. Is this something that is done by experienced coders, and if so do you have any suggestions as far as organizing notes for later use,or just getting better at it.
 
Marshal
Posts: 25930
69
Eclipse IDE Firefox Browser MySQL Database
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So far you've only been writing code, and so you think that writing code is all there is. All of your numbered points are about what code you should write.

But before you write code you need to design your objects. Up to now somebody else has produced a design and then told you to write code for that design, and now you're moving on to making your own designs.

I'll point you to the Wikipedia article about Object-oriented design but I warn you, it goes much farther than you need to go just yet. So don't try to read the whole thing, just go through the section about "Object-oriented concepts". That should remind you of things you probably already know.

For your simple problem: Tell yourself about a MountainBike. What can it do? And what can you do with it? What do you know about it? When you're telling yourself about it, don't talk about programming things like variables and methods. Just talk about mountain bikes.

Hopefully that can get you started.
 
bryant rob
Ranch Hand
Posts: 115
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:So far you've only been writing code, and so you think that writing code is all there is. All of your numbered points are about what code you should write.

But before you write code you need to design your objects. Up to now somebody else has produced a design and then told you to write code for that design, and now you're moving on to making your own designs.



Thanks for the reply Paul. You are correct. About all that I am capable of doing at this stage in my learning is modifying someone else's design. I can also use the bicycle example and modify that design to something else such as a car and use different model cars to show the polymorphism aspect, or reinforce inheritance. Speaking of inheritance, I was reading how some claim that inheritance is overused, and can actually break encapsulation, or one can suffer the yo-yo problem...I feel like I am experiencing the yo-yo problem when I try to modify existing code to produce different or additional output and I do not get the results I was looking for...usually it is having to do with using a counter somewhere... and I'm at most dealing with 3-4 classes. I can only imagine trying to debug an app with 1000 classes.  My point is I really want to understand the concepts. Even though I may be putting the horse before the cart sometimes, I am trying to learn Java as I go so that I would be able to explain it to someone else.


Paul Clapham wrote: I'll point you to the Wikipedia article about Object-oriented design but I warn you, it goes much farther than you need to go just yet. So don't try to read the whole thing, just go through the section about "Object-oriented concepts". That should remind you of things you probably already know.

For your simple problem: Tell yourself about a MountainBike. What can it do? And what can you do with it? What do you know about it? When you're telling yourself about it, don't talk about programming things like variables and methods. Just talk about mountain bikes.

Hopefully that can get you started.



Thanks for the wikipedia link. I have referred to it and linked off of it many times trying to understand OOP better.   As far as the MountainBike example, I have been doing exaclty that (so hopefully I'm learning something), and also with my car example, house example, a restaurant example and others. I probably have spent a little too much time on this OOP section but I don't know what I don't know.

One last thing. Everything I read states Java is a pretty easy language to learn. Well, I finished LSU (Go Tigers!) with an Accounting degree in 3 years and made Deans List each semester. I never needed to go to class with the exception of my calculus and statistics classes. This stuff has brought me to my knees many times over the last few months. It has been challenging and humbling.  I really thought it would be easier than it is.
 
lowercase baba
Posts: 12906
63
Chrome Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have said for years that coding is 90% thinking, and 10% typing.  This is ESPECIALLY true for beginners.  The more time you spend thinking, planning, and designing your code, the easier it will be to write it.

As you gain more experience and practice, that ratio may shift slightly.  Some concepts become almost second nature.  You start to internalize some of the edge- and corner-cases, so you don't spend as much time planning them out...but you should ALWAYS think and plan before you write a single line of Java, or any other programming language. And without a doubt, writing it out in English (or whatever natural language one is comfortable in) actually helps you think through it.

 
Sheriff
Posts: 15913
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's my take: as a beginner, you haven't yet developed an innate sense of what is good design vs. bad design. Your focus is primarily on getting your program to work. That being your primary focus, your designs will tend to be not so good. The irony, of course, is that you're likely going to get a well-designed program to work much faster than you would a poorly-designed program.

A well-designed program is:
1. Simple
2. Understandable
3. Malleable/Maintainable
4. Testable

This is not a complete list of characteristics of a well-designed program but I think it's a good start, especially for beginners. How much time would you spend planning? I tend to agree with the 90% planning vs 10% coding. However, I wouldn't do all the planning up front nor would I do it as a thought exercise. The up-front non-coding planning I do is probably 20% of the time I spend in development, if that. Most of my planning is done writing code. Test code, that is. I subscribe to Jack Reeves' proposition that coding is in fact a design activity and that code is design. So about 60 to 70 percent of my coding effort is spent in writing unit tests and experimenting with different design options. Running the unit tests constantly gives me the feedback I need to determine whether or not I'm heading in the right direction. Constantly reading the code and refactoring it so that it expresses my intent clearly and is organized in a way that makes the design easily discernible and understandable is a very important part of my process as well.

Basically, my development loop is this:
1. Think about a little bit of functionality I want the program to have
2. Write a small test that, when it passes, demonstrates that the program has that little bit of functionality. See the test fail.
3. Write a little bit of code to make the test pass.
4. Refactor the code to eliminate duplication and make the intent of the code clear. Simplify the code as much as I can.
5. Run the tests again to make sure nothing got broken.

This loop is between 2-5 minutes long if I have a good overall idea of what I want the program to do. It can go longer, sometimes up to 15 minutes, if it's a difficult problem that I haven't found a way to break down into smaller problems yet. Typically, however, that loop is less than 10 minutes long. This means I'm constantly experimenting with different options and constantly reorganizing code, renaming things, moving things around, deleting things, adding things. My code is hardly ever "done" until I'm all out of ideas for how to test the program and how to make it easier to read and work with.

This may seem like an advance way to develop but I firmly believe that if new programmers started out learning to program this way, we'd all be able to get a lot more fun and good, working software in the world.
 
Saloon Keeper
Posts: 22634
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The worst of it is that you can catch a lot of static from your boss because while you're thinking, you don't appear to be working. But in fact, the hardest work of any well-designed app is spent thinking. And, in fact, some of the best thinking isn't done in an office chair, it's in bed at 3AM or in the shower. Something about showers seems to activate the problem-solver in many of us.

When I design a system, it generally goes something like this:

1. Consider what the core components of the system are and how they will interrelate between themselves and the outside world.

2. Posit some basic classes to provide and facilitate those components.

3. Scribble some sketches. Usually on scratch paper.

4. (optional) Grab one of my GUI design tools such as ArgoUML if UML diagrams would help.

5. Create skeleton classes. Start by populating them with the essential properties and method stubs. Write JavaDocs as an aid to remembering what these components are supposed to do. I like to include the constraints here as well - for example, if a method should never see parameter "x" less than 2 or greater than 4, document it (and consider how it might handle that when you flesh it out). Also document the range of outputs they should produce.

6. Review everyhing. Throw dead-end stuff away and re-design as needed. Don't be afraid to go all the way back to item 1, if necessary.

7. Consider test-driven design. Designing unit tests for classes and methods according to the contraints you (hopefully) documented in step 5 not only helps you develop more reliable code, it can be used for regression tests when the system goes into maintenance mode.

8. Prototype the supporting infrastructure. Create database schemas, LDAP directories, whatever. Make sure you can do this in such a way that you have one set of infrastructure for the test environment and can generate its production equivalent. Avoid building the production stuff yourself, even if they let you.

9. NOW you can start serious coding. You should have pretty much all the groundwork laid, so it becomes a matter of making it "real".

10. Once everything has been coded, run the test suites (you should have also been testing as you went). About now you are probably ready to throw it to the mercy of the users and management.

11. Create production deployment support. This may be in the form of basic units like WARs and implementation documents, or if you're into DevOps, OS packages, deployement directives (such as Ansible, Puppet, Salt and the like) and/or container definitions.

What I've described is basically the Waterfall process, though. Agile has a lot to recommend it. Agile is basically the same process except that your goals are more modest for a given deployment, yet should look forward to the next stage of development.
 
Paul Clapham
Marshal
Posts: 25930
69
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

bryant rob wrote:Speaking of inheritance, I was reading how some claim that inheritance is overused, and can actually break encapsulation, or one can suffer the yo-yo problem...I feel like I am experiencing the yo-yo problem when I try to modify existing code to produce different or additional output and I do not get the results I was looking for...usually it is having to do with using a counter somewhere... and I'm at most dealing with 3-4 classes. I can only imagine trying to debug an app with 1000 classes.



I never heard of the yo-yo problem before, but yes, I have to deal with that in my own code (which only has 700 or so classes). When I find a bug, the question is "Which class is responsible for this problem?" If I get a stack trace then I have a pretty good idea, but otherwise there are a lot of classes which cooperate in getting things done and I have to flip around between several classes to see which class (or classes) need to be changed to fix the problem. In the latest instance of that process (the last week or so) I went through three iterations of trying things before I found the best (and also simplest) fix. It doesn't help that much of the code was written eight or ten years ago, so even though I wrote it, it's essentially somebody else's code that I'm looking at.

But the yo-yo problem isn't a problem which is mostly caused by inheritance. It's a problem caused by having a large amount of code which is scattered in many different places, and when you have a lot of code you have to divide it up into comprehensible pieces. You could write one enormous piece of code encapsulating everything your program is supposed to do, but then you're going to be yo-yoing around within that. In other words, you can't get away from it.
 
Tim Holloway
Saloon Keeper
Posts: 22634
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I won't say I'm immune, but being naturally paranoid helps me. I do a lot of anti-bugging. A couple of other things assist me, though.

1. Spec document. Before commencing development of a major project I'll generally produce a Functional Specification document that outlines the system, its operation, expected inputs, outputs, and maintenance and diagnostics. It's as much a customer-facing doc as an internal one, To that I may add an Implementation Specification which is where the non-abstract (code-specific) documentation goes. And sometimes an operators and/or app administrator's guide. These manuals make it a lot easier to remember what was done, where it was done, and why it was done.

2. JavaDocs. I expect to be able to spit out a complete JavaDoc package for each compilation unit, if not a combined system-wide unit. The kind of stuff that Sun has done is the bare minimum and I prefer to beef it up with function domain and range information, tables, and diagrams where it will help. JavaDocs are built off HTML so you have essentially the same abilities you would for any website.

3. Logging. Lots of logging.

4. Unit tests. Also integration tests and any other layer of testing that might help.

5. An IDE. IDEs such as Eclipse can provide pop-up cross-referencing of method/variable usage, inheritance and a lot more, including hover JavaDocs/

6. And the most important thing of all: a relatively clueless person who can look at stuff and see what's actually there, as opposed to me, since I "know" what's there. I've spent more time chasing errant commas and similar trivialities than I ever have in getting complex systems to work.
 
Tim Holloway
Saloon Keeper
Posts: 22634
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Incidentally, there's another tool that I've found to be very useful in the early design stages: a Mind Mapper.

A Mind Mapper is an idea organizer such as FreeMind. It allows you to make notes about a project and arrange them in connected hierarchies. Like this sketch I did for a long-ago system.

I use it to keep track of "to-do" items, important modules and to keep track of dialogs, model menu structures and so forth. What I like about Freemind in particular is that although it's a (Java) GUI app, there are easy keyboard shortcuts for almost all common map editing tasks. You can run an outline by simply typing lines and hitting "Enter" at the end of each, spawn a sub-topic by pressing Insert and so on. You can also draw a cloud around important sub-units (One thing I hated about UML was that the finest details had equal visual weight with major components), attach icons to point out items of interest and do all sorts of fancy font and color. And you can export it as HTML for peer review or to MS-Word/LibreOffice Writer as the nucleus of a full spec manual.

A good outliner (such as Joplin) is another option. Or a Post-It™-like program. Whatever helps you stay organized.
Dibs.png
Mindmap for the "Dibs" system
Mindmap for the
 
Rancher
Posts: 912
22
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the biggest problems that I see new programmers or would be programmers face is the struggle to program and code simultaneously: at some point they learn that coding is only the tip of the ice burg and needs to be considered as such, the rest is design.  There are many phases of design too. Don't rush to the coding phase until you have all of the design taken care of.
 
Marshal
Posts: 7778
536
Mac OS X VI Editor BSD Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@OP, have a cow for an interesting topic.

bryant rob wrote:While I have only been coding using Java for 3-1/2 months I find myself getting confused during the process.


Sounds about right. Many would be surprised if would be otherwise. That's true (if not planned ahead) also with more experienced developers than yourself.

Risking to repeat what other great replies already touched, I want to mention you a bit about commercial side. In commercial environments also barely someone's jumps and writes code. Usually there is a planning ahead, what tasks need to be done by describing them in so called tickets, where developer could find just enough context about the problem, actual task that needs to be done, acceptance criteria which gives you clear line when you can know the task you have been assigned you can consider as done. Sometimes tasks appear to be too big when someones trying to describe them, or maybe after discussion developers identify that it is more complicated than somebody anticipated, in such cases tasks getting split into more, less complex tasks until singular developer could implement it in a reasonable timeframe. There are cases when it is only partially clear what needs to be done, or not clear whether that is achievable at all, then one needs to research this blurry area a bit more by trying some dummy experimental implementation so could refine ticket further.

Now, look at your initial post, you seem to be identifying the same things and raising the same questions (great ones), which in commercial environments developers face too. You are on the right path

As others already mentioned, the way you specified the tasks 1-7 are really not the contextual tasks what needs to be done, but rather technical script, which is only little helpful to developer. You can assume that each developer has enough knowledge to figure those out during the implementation of the task. But what they don't want, is to have to figure out what needs to be done, and that what is usually described in simple english (or other language; without programming terminology).
 
Tim Holloway
Saloon Keeper
Posts: 22634
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Incidentally, one of the biggest problems that people coming to the JavaRanch for help is often that they have devised a technical solution and they can't get it to work.

Often, there are very good reasons why it doesn't work, and sometimes why it would never work or should never been considered as a solution at all.

We're all constantly admonishing people not to prematurely optimize, but prematurely solving can be a big problem too. Sometimes we have to ask people to step back and tell us what they want their solution to accomplish, because we may have a more effective solution for the same problem that they didn't know about.

You might have noticed that in my own design checklist, I didn't even begin to design rough classes until step 2. And, like Liutauras has said, in the professional world a project may consist of considerable work even before you get to my "step 1". I have worked in a shop where one of the first things I had to do was prepare a 1-2 page Executive Summary documenting what the system was to be and why it should exist in the first place (and what alternatives were available with costs/benefits).
 
bryant rob
Ranch Hand
Posts: 115
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just want to send a thank you to all of you who have replied to my post so far. Thank you for the words of wisdom and helpful suggestions sent my way. I will be coming back to this thread from time to time in the future and commenting on some of your specific posts but as you probably can guess I really don't know where to begin...it is just so much info.

All I can state for now is I have a simple program in my head where I want the user to be able to enter 5 integers, and my program be able to print to console the average of those numbers. Seems easy, and I can write this code out within 10 minutes, all 45-47 lines...from some logic and some memorization.
But, if I start the design process:
  • Determine my objective
  • How am I going to achieve my objective
  • Which methods will be needed
  • Which methods will be responsible for performing which tasks
  • Determining conditions in case incorrect data is entered
  • the flow of the data, and so forth, all the while actually entering the code into the IDE I have literally spent almost an hour due to editing, and making changes trying to make my code function better, more efficiently, and be easier to read.  I also realize that this is a simple project, and it may not should take me so long, but it does seem like I am learning more than just syntax here, and that is what I am hoping for, and hopefully getting better at "the process" and not just "the coding" will equate to being a better developer.  

    I state this because getting on this forum has done one thing that I never expected, and that is to think about what I am doing before actually doing it. Some may argue that going through Oracles Java Tutorials, or a course on Udemy.com, Coursera.com or some other online platform paves the way to learning to code. Well, I would suggest to them based upon what you have stated to me and that is to think before you code. Again, thank you.
     
    Tim Holloway
    Saloon Keeper
    Posts: 22634
    153
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    1. objective: average 5 numbers. No more, no less. Do not average 4. 6 is right out.

    2. major functions:
      A Read numbers
      B average them
      C print the average

    3.
     
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    fred rosenberger wrote:I have said for years that coding is 90% thinking, and 10% typing.  This is ESPECIALLY true for beginners.  The more time you spend thinking, planning, and designing your code, the easier it will be to write it.

    As you gain more experience and practice, that ratio may shift slightly.  



    Useful to know .Could you please tell  further on, in which direction may the ratio change  slightly as one gain more experience and practice ?
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I'd say as you gain more experience, you spend more time thinking. That's partly because when you're less experienced, you tend to be all about the coding and much less the deep, problem solving type thinking. As gain experience, the language and technology becomes less of burden to you and just becomes another tool to use. The problem solving and thinking part is not so much dependent on the technology and pretty much demands most of our energies. That doesn't change, only how much energy we can actually devote to it.
     
    Marshal
    Posts: 70604
    287
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It gradually changes from 90% thinking and 10% typing to 10% typing and 90% thinking.
    When you have thought about something, and worked it out, you may be lucky and remember how to do it again next time. In which case you can reuse the thought, just as you reuse software. When you recognise something as similar to what you have solved before, it will be easier to solve second time round. And quicker. If you are faced with something new, you will have to work it out just ass beginners have to work out things simple.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:As gain experience, the language and technology becomes less of burden to you and just becomes another tool to use..



    Thanks .
    I think this should  happen in majority of the cases unless one starts working on totally different technology.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:
    Basically, my development loop is this:
    1. Think about a little bit of functionality I want the program to have
    2. Write a small test that, when it passes, demonstrates that the program has that little bit of functionality. See the test fail.
    3. Write a little bit of code to make the test pass.
    4. Refactor the code to eliminate duplication and make the intent of the code clear. Simplify the code as much as I can.
    5. Run the tests again to make sure nothing got broken.



    Best things to learn.

    I have a question. Is it practical everytime to do 3 followed by 4 ? Since in many scenarios I have seen 3 and 4 clubbed.Meaning when you are saying that you are doing coding, during that time frame itself one has to take care of refactoring ,removing duplication etc as after that there would be no time left to do these ?
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:
    This loop is between 2-5 minutes long if I have a good overall idea of what I want the program to do. It can go longer, sometimes up to 15 minutes, if it's a difficult problem that I haven't found a way to break down into smaller problems yet. Typically, however, that loop is less than 10 minutes long.



    Sorry I could not understand.Could you please tell ?. Does that mean everything within say 10 minute loop? (including points 1 to 5, that means thinking about little functionality ,small test , writing bit code,refractor,run tests all within say 10 minutes ?)
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Tim Holloway wrote:

    5. An IDE. IDEs such as Eclipse can provide pop-up cross-referencing of method/variable usage, inheritance and a lot more, including hover JavaDocs/



    I would like to learn this.Could you tell bit more about it or refer me to a reference material?
    Thanks
     
    bryant rob
    Ranch Hand
    Posts: 115
    6
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:As gain experience, the language and technology becomes less of burden to you and just becomes another tool to use. The problem solving and thinking part is not so much dependent on the technology and pretty much demands most of our energies. That doesn't change, only how much energy we can actually devote to it.



    I can see this as my reality at the moment. I am working on a problem in which I have come to understand that involves using an ArrayList to create a list of phone contacts. One might say easy peazy. If I would not have to think about one method being called from another method which is being called from another method within another class which is called from another... not to mention the multiple variables that the return of each of these methods are being assigned to..... so on and so on, and then needing to place a sorting algorithm within its on method and not include it in one of the find methods(because it doesn't belong in the find method) in which I have overloaded with one accepting a contact name, another accepting a contact phone number, another accepting a postal code, and so forth just so the user of the code can search an ArrayList for a contact, and either add a new contact, remove a contact, or modify an existing contact, and or print the list of contacts out in a specific order this stuff might just be easy.  My point here is there is a lot of thinking going on here and without the experience it does seem very overwhelming at times.  So, I had to write notes to make it work for me.
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Functional decomposition is the answer there. What's happening with you right now is that you're overwhelming yourself with all the details. If you were taking a road trip from Chicago to New York City (about 800 miles), it's like you're worrying about every turn, gas stop, food stop, bathroom stop, toll, and accident that could ever happen. You can choose to travel like that but it's very stressful. With modern conveniences like the GPS, you can just enter the destination and take the trip one turn at a time and stopping for gas or personal needs as and when you need to along the way. Back in the day before GPS, we'd have a map and lay out a general route. Maybe we'd plan out a few stops but usually, once you have a general idea of the overall route you're taking, you just deal with things as you go.

    The point is, don't try to plan every single detail ahead of time. Programming is a journey of discovery. As long as you know the general direction you're taking, you can deal with details as and when you need to. Thus, when I plan, I tend to just draw enough of a rough sketch to guide me in the general direction of where I want to be in the end. Definitely try to visualize the end and a few waypoints but don't try to analyze the thing to the umpteenth minute detail.
     
    Tim Holloway
    Saloon Keeper
    Posts: 22634
    153
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Likes 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I'll go Junilu one further. It's really counter-productive to obsess over details when first designing an application. The Agile Methodology is based on setting short-term goals and working for them. Instead of the so-called "waterfall" module where nothing is ready until everything is (and you go over the figurative waterfall), Agile delivers a set of successively-incomplete products. And importantly, the ultimate shape of the product is influenced by feedback from the users along the way, so worrying about details would be pointless. The only details you can be sure of are the ones for the next goal.

    Long before the term Agile was invented, I learned this first-hand when working on projects where I was in very close contact with the users and we found ourselves doing just that.

    As a note to the cynics, Agile in the hands of ham-handed management is no different than any other "Magic Bullet" technology that can be used to abuse people and make them miserable while failing to get things done, so don't discount it on that account. Agile done right is pretty useful.
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Tim Holloway wrote:As a note to the cynics, Agile in the hands of ham-handed management is no different than any other "Magic Bullet" technology that can be used to abuse people and make them miserable while failing to get things done, so don't discount it on that account.


    Unfortunately, there are still a lot of ham-handed managers out there.

    Agile done right is pretty useful.


    And fun and rewarding.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:.

    Basically, my development loop is this:
    1. Think about a little bit of functionality I want the program to have
    2. Write a small test that, when it passes, demonstrates that the program has that little bit of functionality. See the test fail.
    3. Write a little bit of code to make the test pass.
    4. Refactor the code to eliminate duplication and make the intent of the code clear. Simplify the code as much as I can.
    5. Run the tests again to make sure nothing got broken.



    Thanks.I have started trying to do this way,specially 3 and 4 in this order and it makes one feel more in control. Better way of development .
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:
    Basically, my development loop is this:
    1. Think about a little bit of functionality I want the program to have
    2. Write a small test that, when it passes, demonstrates that the program has that little bit of functionality. See the test fail.
    3. Write a little bit of code to make the test pass.
    4. Refactor the code to eliminate duplication and make the intent of the code clear. Simplify the code as much as I can.
    5. Run the tests again to make sure nothing got broken.

    .



    Does this step 1 mean coming up with a Happy flow running ?
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    No, it doesn't. "Whatever" means just that -- it doesn't matter whether it's happy path or otherwise, as long as I'm clear on what that functionality is supposed to be. That being said, I usually do start with happy path scenarios just so I can get the base functionality defined. I will usually do negative testing scenarios after I have most of the positive scenarios implemented.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks.i think that would  mean that for example one may initially hard code any values required ,get the flow working and later on remove the hard coding by reading  from config file.
     
    Campbell Ritchie
    Marshal
    Posts: 70604
    287
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Since this is BJ, please explain how a happy path differs from the downhearted paths we see here so often.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:Since this is BJ, please explain how a happy path differs from the downhearted paths we see here so often.



    Sorry,what is BJ and what does downhearted paths mean?
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:i think that would  mean that for example one may initially hard code any values required ,get the flow working and later on remove the hard coding by reading  from config file.


    That is quite a leap of reasoning you're making there. What you describe is not an unreasonable approach but "thinking about some piece of functionality I want to implement" does not in any way imply what you describe as a specific strategy. It seems like you're reading way too much into my statement than I intended to communicate.
     
    Tim Holloway
    Saloon Keeper
    Posts: 22634
    153
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I had to go back and look that one up myself. "BJ" in this particular instance is one of the two forums the thread passes through: "Beginning Java". Any other interpretations of those initials I take no responsibility for.

    And this, children, is why we urge caution when using acronyms.
     
    Campbell Ritchie
    Marshal
    Posts: 70604
    287
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:. . . Sorry,what is BJ and what does downhearted paths mean?

    BJ is this forum and a downhearted path has to be the opposite of a happy path.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:

    Monica Shiralkar wrote:i think that would  mean that for example one may initially hard code any values required ,get the flow working and later on remove the hard coding by reading  from config file.


    That is quite a leap of reasoning you're making there. What you describe is not an unreasonable approach but "thinking about some piece of functionality I want to implement" does not in any way imply what you describe as a specific strategy. It seems like you're reading way too much into my statement than I intended to communicate.




    From what I understood from "little bit of functionality I want the program to have ", is getting a flow working end to end .That is to say, not with all the functionality but the bare minimum required to get an end to end flow working . Once ,that would then add other functionality and keep doing refactoring . Please correct me if I am wrong.
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It's a bit more granular than that for me. If I was writing a Game of Life program, for example, "one bit of functionality" might be to calculate how many neighbors a specific cell has and that's it. It's not end-to-end but it certainly is going to be an important building block that is common to many flows that I will eventually have to program.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    And what would be that for example if you are to build an online shopping application.What would be the loop that would take less than 10 minutes ?
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:And what would be that for example if you are to build an online shopping application.What would be the loop that would take less than 10 minutes ?


    I don't see a point in your line of questioning. There are many things you can start with for a scope that large. What are you getting at? You are asking oddly specific questions and it's starting to feel like you're just randomly fishing for answers. What's your point?
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:.

    Basically, my development loop is this:
    1. Think about a little bit of functionality I want the program to have
    2. Write a small test that, when it passes, demonstrates that the program has that little bit of functionality. See the test fail.
    3. Write a little bit of code to make the test pass.
    4. Refactor the code to eliminate duplication and make the intent of the code clear. Simplify the code as much as I can.
    5. Run the tests again to make sure nothing got broken.

    This loop is between 2-5 minutes long if I have a good overall idea of what I want the program to do. It can go longer, sometimes up to 15 minutes, if it's a difficult problem that I haven't found a way to break down into smaller problems yet. Typically, however, that loop is less than 10 minutes long. This means I'm constantly experimenting with different options and constantly reorganizing code, renaming things, moving things around, deleting things, adding things. My code is hardly ever "done" until I'm all out of ideas for how to test the program and how to make it easier to read and work with.



    All I want is to learn how to use this way with an example ( which can be any common example say a shopping cart application or online banking application or Notification Engine or any common application ).So that I can try using this way in the next requirement I work on.
     
    Nothing up my sleeve ... and ... presto! A tiny ad:
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    reply
      Bookmark Topic Watch Topic
    • New Topic