Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
What steps can one take to mitigate the risk of a one-person team working on a project, especially when that one person is a rather junior programmer?
I ask because I am that junior programmer, and there is no one available/willing to do things like code reviews. Part of the problem, I suppose, is that I am working on web applications in an embedded software company, so most employees' expertise is in a different area.
Recognising this as a problem is more than most "junior programmers" would be able to do :)
Unfortunately most employers don't see the benefits (only the downsides) in multiple people on the same task.
With lack of understanding from your employer on this point, just stick to all the usual rules, such automated testing, documentation, and source control. I know too well that when working alone on a project, it is all too easy to become complacent.
The truth is that the documentation is not just to help others know what your code does. It helps you too. Source control is not just to enable multiple people to work on a project and merge changes, it helps productivity (in the sense that you can easily revert changes), enforces backups, and gives you good tracking of where your time and effort has been spent.
Source control and automated tests are two things that will help in any environment. Those two things alone will mitigate some of the major disasters (lost work, buggy code resulting from constant changes and refactoring).
Beyond that, stick to the basics: K.I.S.S. Keep your code design as simple as possible, keep your classes simple, follow the Single Responsibility Principle and above all, avoid duplication (which will greatly guide your designs). Make use of every resource you have: message boards, other programmers at other companies, friends from school, whatever you have available to you. Even having a mentor you can send e-mail to is helpful.
Best practices aren't much different than for a larger group. Source control, unit testing, follow a style guide for your language, script everything instead of using manual processes, and try to have at least some high level documentation and comments in the tricky parts of code. For specific decisions that are important and hard to change, like how your code interacts with the database, try to find out what approach a well-designed project uses, if necessary by checking on this site.
Unit tests especially are a great way for other people to quickly figure out how your code is supposed to behave, and to check whether their changes have broken anything.
StackOverflow is full of available and willing people to help solve problems and give advice.
Other than that, be prepared to make mistakes and learn from them.
Oh yeah, and get a copy of Code Complete!
As #MattJ mentioned, the fact that you care enough to try to mitigate that risk implies much more seniority than your current job title purports.
I would say that you should do all of the normal things you do to mitigate risk and, where it's not possible to get another resource, just either do it yourself, or skip that step.
It's the best you can do.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I recently started a career in software development after graduating a couple of years ago in CS. The current project I'm on is a large ongoing project that has it's origins in the 90s with a mix of C, C++, and Java. There are multiple platforms (UNIX, WIN, etc) being supported, older technologies in use like CVS, and some dated documentation in some areas.
The extent of my software development skills stem from going to university as I've had little real world experience. I felt like I had a decent foundation in CS but I cannot but help feel slightly overwhelmed by it all. I'm excited to be part of something so huge but at the same time I feel like it's a lot of information to absorb.
My coworkers have been great people and answer a lot of questions I. My employer hired me knowing that I am entry level.
I've tried poking around the source code and examining how everything gets built but it's on a scale I've never seen before.
How do more experienced people situate themselves when joining a large ongoing project? What are some common tasks you do when getting yourself up to speed?
Good question. I haven't had your exact experience, but in cases like this I like to think, "how do you eat a whale?" The answer is (predictably) "one bite at a time." Reasonable people won't expect you to grasp the whole thing immediately, but they will want to see progress. Perhaps there are some small areas of the larger project that are not too complex, without too many dependencies. Work toward understanding one of those and you're one 'bite' (and/or 'byte') closer to expertise on the whole project.
Being familiar with all existing documentation I would try to get the big picture. Literally.
generate a TreeMap of the source code
I would use GrandPerspective on Mac or WinDirStat on Windows. It will give you some insights about the structure of the project's files (sometimes it gives some hints about the code structure). Having this, you can ask your colleagues for some of the clusters, what they do, how they relate to each other.
learn how to build the project
This is important to have it compiling all the time if you are about to do any changes. Having tests executed at the build time is always a good thing, so ask for it also. Even better if there is some kind of continuous integration server in place. If there is, look at its configuration - figure out how the build is done. If there was no CI server, but you already got the knowledge how to build the project, create such a server on your local machine, and show it to your fellows - they should fell in love with it.
browse the source code with Structure101 or similar tool
This is useful especially for Java projects. This tool does great job. That will give you more details about the code structure, and sometimes about the system architecture. This experience may be sometimes hard, you may learn from this tool that a code is basically a Big Ball of Mud ;)
look for tests, and explore them
If you will be lucky there may be some JUnit, or CPPUnit tests. This is always good to try to understand what those tests are doing. It may be a good starting point to explore the code further.
My coworkers have been great people
and answer a lot of questions I. My
employer hired me knowing that I am
entry level.
You have little to worry about, you're employer knows what you are capable of and your co-workers seem eager to help you out - to be honest most developers love explaining things to others...
From what I've seen, it take truly 6+ years to become fully knowledgeable in a language, so don't expect to become a guru within a year... and even these so called gurus end up learning something new about their language everyday.
Learning a new system (large) will always take time.... the systems were usually not built in 2 weeks but over many years, so don't expect to understand it fully yet. You'll eventually discover what each part does piece by piece.
I know how you feel, because I felt like that once...
"I took a speed reading course and read 'War and Peace' in twenty minutes. It involves Russia." (Woody Allen)
I agree on what the others said before me. You need some tools that give you an overview on the code. I personally used inFusion (http://www.intooitus.com/inFusion) because it gives also other interesting data beside structure.
The method that has worked best for me is to grab a copy from source control, with the intention of throwing this version away...
Then try and refactor the code. It is even better if you can refactor the code that you know you will be working on at a later stage.
The reason this is effective is because:
refactoring gives you a goal for you to aim towards. Whereas "playing" an "breaking" the code is great - it is unfocused.
To refactor code you really have to understand the code.
Refactored code leaves code that has less concepts to retain in memory. If you don't understand a large codebase its not because you are a graduate - its because nobody can retain more than 7 (give or take a few) concepts at a time.
If you follow correct refactoring guidelines it means you will be writing tests. Although, make sure that you will be working on the modules that you are testing as writing tests can be very time consumning (although very rewarding)
Do invest in buying this book at some point:
http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672
But these links should get you started:
Signs that your code needs refactoring and what refacoring to use (From Refactoring - Martin Fowler)
http://industriallogic.com/papers/smellstorefactorings.pdf
A taxonomy of code smells:
http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
Good luck!!!
I agree to the first comment but I also Think that you have to learn and see the big picture in some way. You have to trace the main flow from code at least.
I was in the exact same situation several years ago when I joined a software project with 50+ ClearCase version control vobs, 5 million lines of code, and some of it dating back to the 1980's.
The first thing I did was look through every source controlled directory and made a quick summary of my best guess about what the software in that folder did and what language the code was. You can make a pretty good guess by looking at filenames and any comments or documents in those folders.
I then looked at the build scripts to see if they were readable enough to get an idea of dependencies between different parts of the code.
Finally - and I believe this was the most valuable - throw an IDE like Eclipse or NetBeans on top of the code and start reading through pieces of it. Having the ability to jump to the definition of any functions or classes using the IDE allows you to move around a massive software baseline with relative ease.
Overall, have some confidence - it is unlikely that anyone else on the project knows all of the code, so you don't need to either. Use what other people said to get a good idea of the overall project and interfaces and requirements (if they exist) and poke through the code to get an idea of the most commonly used classes and methods.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
You are working with someone in one project and this someone writes bad code. Not that bad to fire him ar you can`t work with it,
but
person do not follow coding conventions
code is not always covered with unit tests (and it should be)
code is sloppy and do not have comments where it should have them
person do not know design patterns well/do not know at all
put his clothes on your table just as he needs some space.
So how to tell one he need to upgrade his skills, without hurting him? I described something that is a problem. But imagine everything is just fine, except some things that really hurt the project. What to do so that you are still friends, but guy really understood he need to change something?
This is a good candidate for having the entire company do code reviews for a month. You won't single him out (which is good, unless all else fails), and you're better engineers can help him along.
Just stay professional, and point out the problems in your bug tracking, code reviews, or whatever means you have for tracking work items and bugs.
It's the responsibility of the person's manager and the project's PM to determine who is responsible, and to inform the person politely. That is their job, and if they are unable to do this, your project (and probably company) is likely not a very good one to work for.
I would recommend "failing" any code that does not meet the quality criteria. For example, if there are missing unit tests, "fail" the code so that it goes back to the developer to be rectified. This would be similar to having the code fail UAT or something, except it's more of an internal review from team leaders in the development team.
As an example, in one place I worked, I was leading a team of developers. We had PHP production code that was writing unnecessary warnings to the log files, which eventually caused disk space problems and difficulties in debugging the real bugs.
So, to rectify the problem, I laid down the rule: if any code that you've written writes warnings to the log file, the release will fail testing, and you'll need to fix it before it goes any further.
We had almost no warnings being logged on the next release. Now, it wasn't technically a bug, just a code quality issue. The point is that someone needs to be the gatekeeper that reviews and enforces quality controls at some point in the development lifecycle.
Even better, write some automated integration tests that check unit tests exist and code is styled correctly. There are some tools that can check this for you (not sure of the names of them, someone else may be able to enlighten us on that). That way, the build fails an automated, reproducible test. Code would get cleaned up quick smart if that was happening I would say.
You can implement code analysis/styling tools into your build process that enforce certain design and style guidelines. The benefit of this approach is it doesn't single anyone out and it applies to everyone.
Depending on the language your project is using, there are probably tools out there to do this for you. Ex. StyleCop and FxCop for C# projects.
Relax, just invite him for a drink go out and get stoned then explain him the whole situation. The next morning if hopefuly he can still remember, he's gonna understand. If not
this time he's gonna take off all his clothes and put them on your damned table :)
Anonymously leave some books on his desk, like "Code Complete" or "Refactoring".
Assuming you're not his lead, inform his lead of your concerns and let that individual take responsibility for the problem.
write some unit tests that covers his code. He may not know how to write good tests, so he can use yours as an example. Set up automated scripts that regularly run these tests, and send out mail detailing what failed, so that he cannot simply ignore the presence of these tests.
We had a guy at work who only bathed once a week (and no, he wasn't French). And towards the end of the week his BO got pretty bad. We left a bunch of hygiene products on his desk for him to try and give him a clue. Didn't work. I think he started going 2 weeks between baths after that. Phew. This was 20+ years ago.
Coding conventions? Like what? Where to put curly braces?
Missing/bad comments? Well, sometimes no comments are better than gratuitous or wrong ones.
Sloppy code? Maybe so. Post an example or two. Maybe he's a good coder, and you're not that bright. After all, PM's aren't usually that bright, they just know how to kiss ass better than some of us care to.
Design patterns? Bullshit bingo fodder.
But taking his clothes off and leaving them on your desk is strange. IMHO.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Sometimes one needs to dig into someone else's code, understand it and maybe refactor/fix it. So I'm wondering what tools/practices do you use to do that? It's not about any specific language or platform, rather some advises in general.
I myself find it very useful to run the code in question under debugger (if it is possible of course), set breakpoints and step through the code.
Also I've used a few UML tools with reverse engineering features to see the big picture. Visualization works pretty well for me.
There's one tool, that I've used quite a bit: Understand. It's not a UML tool, but it has a bunch of visualizations for the code. For instance control flow diagram for a function, which is not part of UML, but sometimes it's very useful.
I've heard that sometimes people write tests for the code they want to learn, but it hasn't been working for me. Sometimes the code I want to understand is not very testable.
There are other tools, like profilers, dependency checkers, loggers etc. Does anybody use it with any success? And how?
What the first thing use start with? What's the next?
I have been in this situation before... It's not much fun. The best way I've found is to write unit-tests to cover the areas that are going to change. Even if tests already exist, this gives you experience with both the api and behavior of the code you intend to refactor. Additionally, you gain more tests to verify the replacement implementation.
Typically, I divide these kinds of requests into 2 camps:
Fix the bug, not the whole code. In this case, I'd tend to read the code and see if I can easily put in the fix without making major significant changes, e.g. adding 5 lines of code or less. This is where the changes made are like a surgical strike that does minimal impact to achieve the desired result.
Tear down the code and put up much better stuff. In this case, there isn't a good little way to do the change or there are lots of little changes that want to get bundled up into a mini-project where digesting all the code is needed and this isn't a quick minor change. Taking an ASP site and putting it into the latest .Net framework would be an example here.
Determining which kind of change something is requires a bit of practice and experience understanding what someone else may call, "One more thing if you could..." that may be a huge deal but they don't see it that way,e.g. could we add a little module that records any error and sends me an e-mail when something bad happens that may not be so easy after all the other requirements get worked out like what if the code can't send a mail message what should it do.
Do check out nWire. It is an Eclipse plugin, currently for Java & PHP, which analyzes your code and offers code exploration, visualization and search tools. The tool is about understanding the associations in your code: class hierarchies, invocations, instantiations and pretty much everything else.
I find it very useful for digging into piles of code (BTW, for me, even my own code becomes alienated after a couple of months of not touching it).
Are you looking for high-level structure, like modules, namespaces, and class design? Or are you trying to understand the internals of the classes, e.g. how specific lines of code work? Those are two different kinds of analysis tools.
Sort of platform specific, but ReSharper is great for teasing out the hidden meaning of .NET code. I love the "Find Usages Advanced" feature where you can look for sets, gets, implementations etc...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I've been making small scale projects for a while now. I haven't started a large project, yet, because I haven't come across anything which I needed and wasn't already accomplished by some other FOSS. Until now. I want to make a program which will allow users to interactively learn secondary languages (I'm kind of want to make it as close to Rosetta Stone as I can).
Right now I'm the only developer since I'm not sure if I'm biting of more than I can chew and don't want to waste any contributors time.
So far I've been planning how the project is going to work and setting up tools to make the project start smoothly and for it to be readily accessible for when other users are ready to contribute to it. I've set up a SourceForge account, a git repository, as well as a document which lists all the features and what the program is going to accomplish.
A basic break down is that the suite is going to be written in java, and the suite will have the ability to support many languages via their locale. The courses for learning the languages will be written in jython. Course-makers will have the ability to use pre-made jython courses to teach their course, or make their own original ones. I'm hoping this will allow for the software to teach copious languages via many mother tongues.
I'm also planning on having a repository of "released courses" which are ones which I (or people who better comprehend the language) think are top-notch courses. This will hopefully make the program seem more professional and secure to the users while allowing third party participation.
With this in mind:
Are there any fatal flaws or suggestions about my project you would like to make?
Is there anything I'm missing about making a big project in general?
Thank you for your time and effort,
Joseph Pond
You will always be biting off more than you can chew if you don't believe other people should consider your project worth their time. This is much more of a leadership point than a programming point. But seriously, work it out: is this idea something that you believe can happen even knowing that you are currently unprepared for many of the challenges that you are about to face? You've given us a rough outline. You'll be giving others a more thorough explanation, and it will soon become obvious that you've overlooked some stuff. Nobody can keep that from happening to you. Having said that, if you think that you have a good grasp of the requirements of most of the components and you believe you can thoroughly describe the requirements to others with appropriate skills, I'd say go for it.
P.S. -- If you have any mock-ups, that would make it seem like a sweet deal from a prospective developer's perspective. It sounds like the selling point is the extensibility of easily designing new courses. If that's so, give an idea of the basic structure of the Jython. When my supervisor gives me a task that I understand thoroughly, I'd rather he didn't show me how to get started or what design or implementation to use. When I have no idea what he's talking about, the roughest of sketches gives me days of a head start.
Are you also the only analyst, translator, technical writer, and tester? This sounds like a large undertaking for one person. Do you have a deadline? In my opinion you will need at least another developer and tester. Even more if you have tight deadlines.
Just find the right person who really agrees with your idea and will take the ownership.
I had been involved in several projects but I dropped out some and only worked on the one I really interested in. So, look at it in the reverse side, looking for a contributor is not easy and must find the person has the things I mentioned about. Then, you can talk about keep contact,, system... project manage..etc. If you can't find the right person, even you have a good system, you are just wasting your time and going nowhere.
Okay, a couple things. First, it's better never to do a big project. Do lots of small projects instead. If it works out that what you get at the end is a big thing, that's good.
Second, a lot of times what works best for this of thing is to think about how you can make something to make it all easier. in this case, you have two issues: making something that does the various operations needed to display and give feedback (I'm working through a Rosetta Stone course myself, they're pretty cool.)
You're really thinking about a course authoring system; you can't write all the materials for all the languages, so you have to make it easy to do the authoring.
This sounds like a job for a DSL, a domain specific language.
And it sounds like a really cool idea.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
There are numerous Agile software development methods. Which ones have you used in practice to deliver a successful project, and how did the method contribute to that success?
I've been involved with quite a few organisations which claimed to work in an 'agile' way, and their processed usually seemed to be base on XP (extreme programming), but none of them ever followed anywhere near all the practices.
That said, I can probably comment on a few of the XP practices
Unit testing seems to prove very useful if it's done from the start of a project, but it seems very difficult to come into an existing code-base and start trying to add unit tests. If you get the opportunity to start from scratch, test driven development is a real help.
Continuous integration seems to be a really good thing (or rather, the lack of it is really bad). That said, the organisations I've seen have usually been so small as to make any other approach seem foolish.
User story cards are nice in that it's great to have a physical object to throw around for prioritisation, but they're not nearly detailed enough unless your developer really knows the domain, or you've got an onsite customer (which I've never actually seen).
Standup meetings tend to be really useful for new team members to get to know everyone, and what they work on. The old hands very quickly slack off, and just say things like 'I'm still working on X', which they've been doing for the past week - It takes a strong leader to force them to delve into details.
Refactoring is now a really misused term, but when you've got sufficient unit tests, it's really useful to conceptually separate the activity of 'changing the design of the existing code without changing the functionality' from 'adding new functionality'
Scrum because it shows where the slackers are. It also identifies much faster that the business unit usually doesn't have a clue what they really want delivered
Scrum.
The daily standup meeting is a great way to make sure things stay on track and progress is being made. I also think it's key to get the product/market folks involved in the process in a real, meaningful way. It'll create a more collaborative environment and removes a lot of the adversarial garbage that comes up when the product team and the dev teams are separate "silos".
Having regular retrospectives is a great way to help a team become more effective/agile.
More than adhering to a specific flavor of Agile this practice can help a team identify what is working well and adapt to a changing environment.
Just make sure the person running the retrospective knows what he/she is doing otherwise it can degenerate into a complaining session.
There are a number of exercises you can take a team through to help them reflect and extract value from the retrospective. I suggest listening to the interview with Linda Rising on Software Engineering Radio for a good introduction.
Do a Google search for "Heartbeat retrospectives" for more information.
I've been working with a team using XP and Scrum practices sprinkled with some lean. It's been very productive.
Daily Standup- helps us keep complete track of what and where everyone is working on.
Pair Programming- has improved our code base and helped remove "silly" bugs being introduced into the system.
iterative development- using 1 week iterations has helped up improve our velocity by setting more direct goals which has also helped us size requirements
TDD- has helped me change my way of programming, now I don't write any code that doesn't fix a broken test and I don't write any test that doesn't have a clearly defined requirement. We've also been using executable requirements which has really helped devs and BAs reach requirements understandings.
kanban boards- show in real time where we are. We have one for the Milestone as well as the current iteration. At a glance you can see what is left to do and what's being done and what's done and accepted. If you don't report in your daily standup something pertaining to what's on the board you have explaining to do.
co-located team- everyone is up to speed and on page with what everyone else is doing. communication is just-in-time, very productive, I don't miss my cube at all.