As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am a final year Computer Science Student and as part of my Bachelors degree I am doing a project on Data Mining of Microarray DNA expression data. I will have to develop a few algorithms such as Bayesian Networks to run on my datasets to find out how each variable(genes) affect each other.
As part of my Project Proposal I have to talk about which methodology I will use to develop my software. From what I have learnt in school and from extra reading I find that the Incremental Development model seems a good idea. I would run 2- 3 iterations of Plan, Design, Implement until I get the full functionality of the software. Could somebody with more knowledge than me please tell me it this sounds like a good idea.
The reason why I am not 100% sure which methodology I would use is because I don't have a team to work on the software, I don't have a client with requirements and I am very limited in terms of the amount of time to work on the project as I have 3 other modules. All the methodologies which I have read about seem to be for big software projects with teams of developers. What do you do if you are just 1 person and focusing mainly on getting 3-4 algorithms to work rather than focusing on getting broad range of functionality.
I was also thinking of using UML to get a better idea what I want the software to do and using like a stripped down version of an Object Oriented Methodology.
My guess would be I would have to use parts of more than 1 methodology at a very basic level but I just can't pick.
I am very confused and lost on the subject so any help is greatly appreciated.
Thank You,
For these types of work, I would suggest not to pay much of attention to methodologies, because after all, what matters is the algorithm. But, for the sake of having a response for your dilemma, I would suggest using XP (eXtreme Programming). Why?
Is light
It doesn't require filling many papers as RUP & others
Is more suited for changing evironments, such as yours
Just take a fast search at Google for XP methodology and you'll get a bunch of useful results. ARUP (Agile RUP) might be worth looking also.
I hope I can help you.
XP/TDD is harmonious with the scientific method; each iteration is a theory, the tests are experiments
It takes a lot of discipline to follow a methodology while working solo, make sure you pick one that isn't labour intensive or you'll never live up to it.
If I was back at school in your situation with what I know now I'd probably go for Test Driven Development. Unit tests are ideal for testing algorithms and will leave you with a body of tests that you can use to demonstrate that you did follow a methodology.
Your idea to do the project in several iterations of plan, design, code and test is fine however with small projects it's sometimes difficult to resist the urge to do it all at once.
In case you do get carried away and finish the project in just one or two iterations, keep notes about the order in which you did things (ideally use a version control system) so that you'll at least be able to fudge your documentation to make it look like you used several iterations. Not that I'd endorse such an approach of course ;-)
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
While many ask questions about where to find good books or tutorials, I'd like to take the opposite tack.
I consider myself to be an entry-level programmer ready to move up to mid-level. I have written code in c, c++, c#, perl, python, clojure, vb, and java, so I'm not completely clueless.
Where I see a problem in moving to the next level is learning to make better use of the literally hundreds upon hundreds of libraries available out there.
I seem paralyzed unless there is a specific example in a book or tutorial to hand-hold me, yet I often read in various forums where another programmer attempts to assist with a question. He/she will look through the docs or scan the available classes/methods in their favorite IDE and seem to grok what's going on in a relatively short period of time, even if they had no previous experience with that specific library or function.
I yearn to break the umbilical chord of constantly spending hour upon hour searching and reading, searching and reading, searching and reading. Many times there is no book or tutorial, or if there is, the discussion glosses over my specific needs or the examples shown are too far off the path for the usage I had in mind or the information is outdated and makes use of deprecated components or the library itself has fallen out of mainstream, yet is still perfectly usable (but no docs, books, or tutorials to hand-hold).
My question is: In the absence of books or tutorials, what is the best way to grok new or unfamiliar libraries?
I yearn to slicken the grok path so I can get down to the business of doing what I love most -- coding.
Give a good programmer a manual and they can figure it out quickly. It is not reading books or tutorials that makes you a good programmer, it is actually programming. Practice. You want to be better and learn better, write more code. Set small coding goals or think of a simple application to make. The more you write while looking up syntax in books and tutorials, the more those syntaxes and practices will "click." The reason many are able to "grok what's going on in a relatively short period of time" is because most programming is just syntax.
I'll give you a personal example. I picked up a book on Objective-C to figure out iPhone development. Sat there reading it all last summer. Didn't know squat when I sat down to write the application I designed up in Photoshop. Sure, the ideas are up in my head, but I did not have any practical knowledge to execute them yet. At first the syntax was extremely confusing to me, but I have a lot of experience with programming in general, animation, and UI design, so once I "memorized" the syntax, the code started flowing more naturally. Now I can write Obj-C pretty fluidly without a manual and have better understanding of what task will be difficult and what will be easy.
My question is: In the absence of books or tutorials, what is the best way to grok new or unfamiliar libraries?
How about doing what you just did: asking a question here on StackOverflow? From my experience, questions of the type "how to do task A, B or C using library X" get answered fairly quickly, especially if they are beginner questions, and no matter how esoteric or outdated the library might appear to the questioner. In fact, on several occasions I have witnessed such questions being answered by the developer of the library himself.
Even if a library seems to have "fallen out of mainstream" quite a long time ago, chances are that there are still a few people here on SO who are using it or have used it at some point in the past.
Most importantly, you no longer have to "spend hour upon hour searching and reading [...] discussions that gloss over [your] specific needs, or examples [that] are too far off the path for the usage [you] had in mind", because you can tailor your question here on SO to your very own personal needs.
Libraries provide developers with a domain specific set of concepts with which to solve problems, not unlike natural (spoken) languages. The similarity is deeper than that: the same way knowing more natural languages makes it easier to pick up a new one, experience with more libraries eases the transition into using a new one. There's no magick bullet here: the more experience you have, the faster you progress because you can anticipate what using the library to solve the task might look like.
That aside, these are the things I find help when picking up a new library:
working examples with source, like the SmartGWT showcase
small API/simplicity, like XStream or CvsReader
high quality documentation, like the one from hibernate
The bet way to learn without books is in my opinion to start programming. Solving the problems which are facing you will teach you how to use the library.
If you want to inspect or search or learn a .NET assembly - Reflector. Its free, and very powerful.
http://www.red-gate.com/products/reflector/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm currently learning to program, and I didn't take CS classes so I'm basically starting out on the bottom. I have been putting together code on and off for many years, but haven't really had a good understanding of essential concepts needed for enganging in bigger projects. Object-orientation is an obvious one, and I feel I'm beginning to understand some of the concepts there. Then there is a lot of buzz and methodology, such as MVC, UML, SCRUM, SOLID and so foth and so on.. I've looked at many of these but I'm always stumped as most explanations seem to require some understanding of other concepts.
I want to learn this stuff the "right" way, so where do I begin?
What are the overarching constructs I need to understand that enable me to understand all the underpinnings of software architecture/design/development?
What am I missing?
Are there constructs and concepts that can and should wait until I've cleared the foundation?
The SOLID principles are probably the most important.
From those you understand the motivation behind using a pattern such as MVC, why people think of persistence ignorance as important and so on. They are at the core of the majority of good practices.
Loose coupling, high cohesion.
And as for books, Code Complete covers almost everything at some level, at least.
Software development is a HUGE arena and you should be careful that you don't take on too much too quickly. Unless you're going to go in the direction of functional programming I'd suggest you start off by making sure you fully understand the concepts surrounding OO design and programming as this should be your foundation.
Once you understand that well you'll be able to understand design patterns a lot better and get a feeling for when to use them.
I'd suggest you try out a few languages till you find one you feel comfortable with, personally my favourite language is Ada which is a very pure OO language but in the business world I work in C# which still has a lot of issues but these are outweighed by the more vibrant job market.
I wouldn't worry too much about Scrum at this stage as you need to focus more on your dev skills before worrying about project management.
The most important thing is to work with as much code as possible, download lots of good reference solutions and work through the code till you understand it, and try and keep an eye on the development trends.
If its viable you may also want to considering attending some developer conferences too as these can be very inspirational.
Stay away from ACRONYMS (including those you've listed) and Methodologies(tm). At least in the beginning.
Read good books. Start with this one: Pragmatic Programmer. Learn algorithms and data structures, possibly from Introduction to algorithms by Cormen et al.
Write a lot of code. Practice is more important than anything else.
How to test software with unit tests. Being able to do that will solve 90% of all the other issue automatically since you can't test while they are around.
When you know how to test, you can start on advanced topics like design.
I'd recommend "Object Oriented Analysis and Design with Applications" by Grady Booch et al. The latest editoin has detailed explanation of concepts of OOAD including MVC, UML (which he invented), and discussions on how to manage the whole process of software development. The second part of the book exemplifies all this by developing 5 sample systems (with sometimes orthogonal aspects from the very core).
Another good one is of course Design Patterns by GoF which will give you an idea of loose coupling, ways to efficient encapsulation and reuse of code, etc
For what concerns the algorithmic part, take any book which is not bounded to a particular programming language. My favorite is Introduction to Algorithms by T. H. Cormen et al, it gets a bit theoretical at some points, but I especially like it when they are proving certain things and not just asking you to believe it.
When you are working with any modern general purpose language, it is probably a good idea to get a handle on patterns (MVC or Model-View-Controller is one). The book by the "gang of four" is a must read for this, or at least research a few and use it as a reference.
clicky
Refactoring is another concept that should be in your arsenal. The book by Martin Fowler on this subject is a very nice read and helps understand the aforementioned patterns better also a little explanation about UML is included.
Can't post more than one hyperlink so...
search on amazon for: Refactoring, Improving the design of existing code
When you want to communicate your designs UML (Unified Modelling Language) is the 'tool' of choice for many people. However UML is large and unwieldy but Martin Fowler (again) has managed to boil it down to the essentials.
search on amazon for: UML Distilled (make sure you get the most recent one)
SCRUM is one of many methods that is used to manage software development groups, I do not think there is much merit in learning that when you are just starting out or on your own. Especially not in detail.
Hope it helps...
PS: SOLID I haven't heard about yet, somebody else has to help you there.
You'd have a decent foundation if you surveyed basic Data Structures, Algorithms, and Algorithms Analysis.
I think that you should start coding real world problems to get a feel for problems in the programming domain.
Then you have a better background to understand why objects are important. Then, after managing objects, you will learn why patterns and OO principles are important.
Personally, I highly recommend the Agile Software Development, by Robert C Martin.
But it may be a long and tiresome read unless you have a feel for the problems being solved. I'm afraid that you may need 500-1000 hours of coding at the minimum before you get an appreciation that the problems being solved are real.
And it probably takes 7000+ hours before you develop an instinctive heart-felt pain from merely reading the problems, making this sort of book become the page-turner that it should be.
Regrettably, many of the sound practices that you should develop are only appreciated after having to live with your code over time. If you just do many excercises and abandon the code afterwards just "because it works", then you are missing out on the greatest pain of all. It is a luxury our industry does not have, and "technical debt" is a very very real and costly to those with large code bases.
I feel kinda silly answering my own question like this.. :) But one valuable resource I've found for learning to write code, is the Euler Project at http://www.projecteuler.net
It's basically a collection of mathmatical problems that you solve by writing your own solution to it. Once you've found the answer to a particular problem, you're allowed access to that problem's forum where different solutions are discussed. I was amazed at how much I was learning in a) solving a challenge, b) reading about other peoples approaches and c) how many programming languages there are out there! :)
The problems start out easy (you can tell by the number of people who's solved them) and progress to harder and harder problems.
Currently I'm working on problem #3, having solved the previous two... I recommend you start chippin' away at them, no matter your level!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are some solo developer programming methodologies for smaller projects?
Just about any development methodology will work in a solo environment except for those that explicitly require a team (such as side-by-side programming). But even then you could get around that by just creating some imaginary friends/teammates or developing a multiple personality disorder.
Even as a solo developer you can use methodologies applied to large development teams.
Write a Spec.
Layout a UML.
Do pencil-and-paper UI design.
Hallway testing: If your expect a large crowd, ask Mom if it's easy to use.
Peer review: You can build ad-hoc review teams with other solo developers.
Keep an up to date schedule.
and so on...
I solo develop all the time, and these practices keep me in line with my own work and give my bosses a great resource to know what I've done and how far along I am. And they keep me on track, to boot!
The rubber duck methodology comes to mind:
http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
Many agile techniques work great solo:
User interviews and stories: If you don't know what your users want, why would your software be useful?
A simple spec: Or even just be a mission statement. "Let people broadcast short messages to their subscriber lists." "Use in-degree to sort internet search results." "Let people collaboratively answer programming questions." Whatever.
A strictly-ordered todo list: Helpful to keep you from drowning in thoughts.
Tangents log: A good to-do list has a "to-don't" component, so you don't obsess over things you aren't going to do (yet).
YAGNI: Stay on target. This is very important when working by yourself, because no one is there to tell you "No! Don't reinvent dynamic typing in Java! Get back to the project." To-don't lists help with this.
Test-driven development: Writing tests forces you to think about the end result, rather than getting bogged down in implementation details. You'll get bogged down enough anyway; no need to make it worse.
Frequent releases: Make yourself stick to deadlines. "We'll have a feature-complete version that includes user stories 1-4 by Friday. It won't connect to the network or save data to disk, but XYZ..."
User testing: Have your buddies look at what you're making on a decently frequent schedule -- maybe once a month, maybe every week, depending on how many friends you have and how much beer/pizza you want to feed them. Pay very close attention to what they say and do and think when using the software.
And other things that only seem like they make sense in big projects can help a lot:
Source control: Install git. It's bone simple. Use it. Don't obsess over it.
Off-site backups: Y'know. In case of house fires or floods.
A blog: But you're only allowed to write there when a release comes out. ;) Also helps you build an audience for your product before it even ships.
Hope this helps! Solo programming on a large project can be very daunting.
Follow what is laid out in this Stack Overflow question:
What Tools/Techniques can benefit a solo developer?
Also. Use Source Control. You wouldn't believe how many times I've been bitten by that on personal projects.
There's this:
http://en.wikipedia.org/wiki/Personal_Software_Process
It's probably overkill
The issue is more a question of what you are comfortable with and what problems you hope to solve. Most methodologies are used by a solo developer at some point (pair programming is a notable exception). The issue is are you actually alone, or just working by yourself? I have found that it is invaluable to have people I can bounce ideas off of. Furthermore having someone else to look at you code (peer review) is a great way to find issues that you just cannot "see". So to agree with Aiden Bell "Programming on your oen is uncool."
I would try and connect to a community (like SO) where you can bounce ideas off of others. Then you need to build your methodology in such a way as to allow for interruptions when you send an idea out.
Does that make sense? Why are you programming alone?
Pat O
Not really an official methodology, but I have done a lot of solo development (independent consultant and ISV), and here are the things I have found to be important:
Find an online organization (like
oisv.com) to share thoughts and
ideas
Make sure you take time to interact
with actual people in the real world
Set project goals, deadlines, and
milestones
Take time to do appropriate up-front
design and project planning
Set aside working hours are stick to
them
Don't work too much and burn yourself
out
Nothing is ever perfect, so strive
for good code that works, not
perfection
Get some non-programming hobbies
This is more of trick than a methodology. When you're debugging, explain the bugs out loud to yourself as though you were trying to explain it to a co-worker. It feels silly, but forcing yourself to articulate the problem out loud often reveals what the problem is.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have had a talk with a friend of mine about the relative vulnerability of different types of IT workers to unexpected unemployment (e.g. layoffs, company going out of business, obsolete skills etc.)
as it seems COBOL developers (or maintainers?) seems very secure in their positions, regardless of the state if the economy or even how good they are. With so much critical COBOL code being around on the one side and the deminishing number of COBOL know-hows on the other , it actually makes sense to recommend someone starting their way in the IT world and looking for a relativity secure job to study and intern in COBOL!
what do you think ?
I started as a programmer with Cobol more than 10 years and worked with Cobol at different institutions then for several years.
Cobol as a technology is fairly easy to learn if you know any imperative programming language.
Cobol itself differs a lot on various platforms and versions - thus it is difficult to study the right version before hand.
The real challenge with Cobol is not the technology, but the complexity of the underlying business and the lack of documentation of the systems/programs. Thus the real value of a lot of COBOL experts is in fact not the actual COBOL knowledge, but the understanding of the business.
I think it makes sense to be a good software developer. For me personally, your question sounds a bit like: "What silo should I occupy to feel secure about my job and stop improving myself?" I know you didn't mean exactly this. But anyway, that's not the best motivation for choosing a career path.
I'd say: try tinkering on some COBOL code. If it's fun for you, go for it! Just as for dozens of other things you should try.
You have to understand that the arguments you made, are relative to time, that is now. We have seen time and again, how technologies seems so prominent at time t and becomes obsolete at time (t + 0.001). Though your arguments rotate around the very fact that COBOL is more or less obsolete, but they may find a new way to deal with it and again you become out of job. So here's rule number 1:
Never rely on one single technology.
With time, they always find ways to have lesser and lesser resources do the same thing. All you can do is to be a smart software professional. When you get the core part of computer programming, technologies wont matter, with time you could just learn them. So here's the second rule:
Don't just try to expertise a
technology, expertise software
engineering
Finally, to survive in IT you always need to be cutting-edge-aware. Also immaterial of all the above, you can still be laid off depending on the harshness of the recession. So finally:
Keep a back up line of work ready,
tommorow IT industry might not be
there :)
Try it, and if you like it then study it seriously.
If you learn it too well you may find you end up stuck in a COBOL role with no way out; it begins slowly and then you are drawn in because the knowledge is very specialised. If you enjoy it, that's fine - but if you try it and don't like it, then don't continue.
IMHO, It always makes sense to study a new language.
It's true that there's a lot of COBOL code running today, and much of that code is mission critical. However, how much actual COBOL coding is happening? I see large enterprises gradually replacing those COBOL systems.
From a practical standpoint, there's a huge base of legacy COBOL code running a lot of systems out in the world (many of them mission-critical) and it's likely cost-prohibitive to replace all of that software any time soon. The average COBOL programmer is probably nearing retirement age. Therefore one could reasonably assume that there will continue to be demand for new COBOL programmers for some indeterminate amount of time to come.
From a personal development/enrichment perspective, it certainly makes sense to study COBOL (and any number of other technologies both new and "less-new".). I'm not sure I'd put it near the top of my list, but its historical significance is reason enough to put it on the list. Somewhere.
My guess is that one of the reasons COBOL programmers (I'm a Fortran programmer, similar situation I suspect) are relatively secure is because they have oodles of experience; you won't get this from learning the language. Rather than ask how many COBOL jobs are there, ask yourself how often you see a COBOL job advertised. I think that it is much easier to hold on to one of these jobs than to get one.
And, of course, when one is advertised, you're in competition with all those very experienced currently-working-in-COBOL programmers.
Regards
Cobol developers are secure in their positions because their code makes money. It is not a horrible language to learn. Actually, it is rather nice once you grok the structure of it.
But it is only one tool in your tool box, you should have several.
I'd say it is not a complete nonsense to learn COBOL, as long as it is not the only technology you learn.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What Delphi coding standards document(s) do you follow?
Our company is looking at putting some better coding standards in place, to improve our code’s readability, reviewability, and maintainability. We’ve come across CodeGear’s “Object Pascal Style Guide”, but it hasn’t been touched in quite a while and I imagine a number of people have made some local improvements or additions. I’ve come across some published variations and other documents, which I will list, below.
NB: I do not want to start a style war. I just want to know what standards you follow, and why.
Thanks.
UPDATE: Well, the "JCL Delphi Language Style Guide" seems to be the clear winner! Thanks!
Project JEDI Delphi Language Style Guide With JCL Additions
(An extension of CodeGear’s “Object Pascal Style Guide”)
https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide
(Thanks to Jeroen Pluimers and AmigoJack for reporting that the old links had died.
And in case this latest link also dies, here's its Internet Archive link, for good measure.)
CodeGear’s “Object Pascal Style Guide”
http://edn.embarcadero.com/article/10280
Econos – Coding Standard Document
(Subtitled “Delphi 4 Developer's Guide Coding Standards Document”.)
http://www.econos.de/delphi/cs.html
About.com’s “Delphi Identifier Naming Conventions”
http://delphi.about.com/od/standards/l/bldnc.htm (via Wayback Machine)
It really doesn't matter as long as you pick one and stick to it. A coding standard is like a dialect, and as long as everyone on the team speaks the same dialect, you're fine.
That said, why not pick the same standard as your runtime library (VCL) and documentation use? Then you will all be speaking the same dialect and you will have an easier time reading the runtime library code. And there are plenty of code examples to illustrate coding conventions.
There can be a tendency to over-engineer coding standards to the point where they get in the way of writing code.
I agree with Jozz’s comment. You can look at all the recommended standards, pick one and force it upon your coders or you can get your team involved in the process.
In my experience, the best way to get a team engaged is to have the team come up with the idea and the benefits of adoption. Your existing talent is your best resource. Likewise, they can be your ultimate enemy if you force them down a path they don’t buy into.
So, take a look at your existing coding variants and get the team together for some vibrant discussions on:
The reasons for adopting a coding standard.
Essential considerations in standardization.
Surfacing any insecurities in the team surrounding this issue.
Finding a point of agreement. What's important and what's not.
Establishing some corporate objectives so everyone feels like they are working towards a common goal.
Get the team to sell the benefits of standardization to themselves.
The most important objective must be to establish a ‘standard’ that best serves your team and your company.
For some inane historical reason, the coding standard at my work is to have all keywords in uppercase, in both delphi and sql. Thank god for caps lock.
CodeGear’s “Hungarian peanut butter”, for naming identifiers
http://dn.codegear.com/article/27983