Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
   and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Manifesto for Agile Software Development

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Development 101

What is Agile Development?

"Agile Development" is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD).

While each of the agile methods is unique in its specific approach, they all share a common vision and core values (see the Agile Manifesto). They all fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system. They all involve continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the software. They are all lightweight, especially compared to traditional waterfall-style processes, and inherently adaptable. What is more important about agile methods is that they all focus on empowering people to collaborate and make decisions together quickly and effectively.

The Evolution of Agile Development

Many of the individual principles and practices that are promoted by agile development have been around for years, even decades. As opposed to implementing these best practices piecemeal, agile methodologies have "packaged" various customer, management, and in some cases, engineering practices and principles together in a way that helps guide teams through the process of rapidly planning and delivering working, tested software. Each of the agile methodologies combines both old and new ideas into refinements that are certainly greater than the sums of their parts.

While it is true that many of the practices associated with agile development have been around for quite some time, the average software development team has yet to embrace many of the principles and practices. Even today, the average software team does not iterate, does not deliver software incrementally, and does not practice continuous planning nor automate testing. Now that these practices have been combined in a manner that can more easily be understood and adopted, the trend appears to be rapidly changing for the better, especially during the last several years.

As with any new way of doing business though, Agile methods have generated quite a bit of controversy within the software community. Yet since their emergence, in project after project, they have continued to deliver higher quality software systems in less time than traditional processes. If you are a software development professional, you definitely owe it to yourself to become familiar with the theory and practice of agile development. Hopefully the information presented on this site can assist you in learning what agile is all about.

[Source]

Don't try too hard

By Yousuf Ahmed

Don’t try too hard!

This is probably the most important lesson I have learnt from my deep involvement in agile transformation initiatives over the last decade.

I have seen too many projects fail where the primary focus has been in implementing steps of a specific agile method – whether the environment is ready for them or not. Examples are of many types - a daily scrum is a great tool – but forcing folks to join a daily meeting where there is not a whole lot changing in what they do may prove counter-productive.  4 week sprints are great – but don’t make much sense for a maintenance team. Test driven development is fabulous – but is a test for every getter and setter really needed?

... I can go on.

Successful agile projects begin with focusing on the fundamentals – and I find it helpful to refer back to the Agile manifesto and its core principles to reinforce these fundamentals.

Agile is concerned with delivering value in an efficient and timely manner - and the different agile methods have given us many great processes and tools to achieve these goals. But most importantly – agile recognizes that the success of a project depends on the people and their level of commitment. At its core, agile is about collaboration, transparency and trust. Agile tools and processes are enablers that help facilitate teamwork and provide a roadmap for efficient execution.  But they need to be used judiciously, ensuring that they help increase the quality of teamwork. Used literally where they don’t necessarily fit, these very tools can alienate the team and ruin the chances of success.

Ken Schwaber (co- creator of Scrum in “Agile Project Management with Scrum”) describes Scrum as a practice of “the art of the possible” – which very aptly describes the spirit of agile – keep the core principles in mind, and adapt the tools to work properly in your environment.

Having said that – it is important to have some sort of a guideline and set of rules, some level of prescriptiveness and discipline in your project, and as a thinking project manager – you are going to need to define these rules for your project yourself.  Don’t try to implement a method just because it exists, but do figure out a process that fits your needs – and then make sure it’s followed. Here are a few key best practices which can serve as a guideline to help define the specific rules for your project.

·           Build trust among team members, including all business stakeholders

·           Find ways to collaborate, and effectively communicate – a daily scrum is one possible way, but adjust the times and frequency appropriately

·           Do build a backlog – knowing what you are dealing with is important

·           Split the work into manageable chunks – use iterations, sprints, or release plans as tools when appropriate

·           Make testing a part of your team’s development culture.

·           Review and communicate progress regularly – in whatever form is best understood by your audience. 

·           Adjust and tweak your methods based on regular retrospection.

Source:  http://agile.vc.pmi.org/Community/Blogs/tabid/172/entryid/2053/Dont-try-too-hard.aspx

Tips for Choosing the Right Project Management Software

Unless one has been living under a rock for the last thirty years, it has become clear that managing a business in modern times is no easy feat. The internet and the information revolution have presented enterprises with unprecedented access to some of the most cutting-edge tools to help ease this burden. With such a plethora of options, choosing the right management software can be confusing. By examining a few important variables, the project manager can avoid wasting unnecessary time and aggravation when deciding what software is right for him.

Successful business operations rely on effective correspondence. What was once able to be accomplished by a few individuals now is achieved by project management software. It is of utmost importance when choosing a system to ensure that it provides the ability to communicate with clients in real time and gives a platform for conference calling while having the capability to post any feedback required. Simply put; the more channels to correspond between different parties, the better the overall outcome of the project.

Look for a platform which allows individuals to manage and schedule their own tasks. Although these duties need to be centralised within the system, different parties should be empowered to take on their own workloads while allowing them to work around their own schedules. One of the biggest snags of any project management system can be avoided here; that is, lack of internal efficiency.

Another critical component of project management is the ability to centrally store and retrieve files. It is well known that many companies have seen great deals of revenue lost simply because information was difficult to access. Storing data that can be easily recovered while under the umbrella of one streamlined program allows for on-the-fly adaptations whenever necessary.

Although information storage and cross-channel communications are vital, data and subsequent workloads need to be shared between different organisational levels. Make certain that the project management software chosen can cope with such complex operations. It should give the user an easy means to place different tasks in different folders and allocate these subsections into a user friendly structure.

These are to name but a few of the options one needs to examine when choosing project management software. By implementing the correct platform, projects can be completed on time and within the allocated budget. Data can be centrally stored and easily accessed. The management team can perform their tasks efficiently and ultimately, this internal competence will lead to very real external results.

{Source]

Software Process Improvement (SPI) Best Practices

by Scott W. Ambler

1. Be aware of your organization’s current culture. One of the significant forces that affect the success of your process improvement efforts is the culture of your organization. Organizations with cultures that are positive toward process improvement are likely to want to supply a quality product with reasonable business returns, have middle managers that are willing to set and work toward targets of meeting your organization’s needs and business goals, and have senior management leadership that is willing to launch and sustain a long-term change effort.
2. Expect to change your organization’s structure and culture. Process, organizational structure, and corporate culture all go hand-in-hand – change one and you will affect the others. 
3. Keep it simple. A common mistake that organizations make is to over specify the processes that they intend to follow.  Never forget that your goal is to produce working software that meets the needs of your user community and that your staff likely has a pretty good idea of how to do this although they could help with a little guidance from time to time.  Give them just enough guidance for their needs.  An example of a well defined, yet simply defined, process is the Agile Unified Process (AUP).
4. Align your software process with business goals and objectives.  You could have the best process in the world, but if it doesn’t meet your organization’s goals then it doesn’t matter.  Do you intend to build a portfolio of applications that integrate with, and build upon, one another?  If so then portfolio management is important.  Do you intend to sell shrink-wrapped software to be used by millions of users?  If so then architecture may be less important to you in favor of getting a product to market quickly.
5. Regularly hold retrospectives.  A retrospective is a process improvement meeting where you ask four fundamental questions: What did we do well that if we don't discuss we may forget?  What did we learn?  What should we do differently next time?  What still puzzles us?  Retrospectives can be simple 15 minute discussions or formal meetings over a day or two.  The goal is to learn from your experiences.
6. There's a serious difference between "lessons learned" and "lessons indicated".  The result of a retrospective is a collection of lessons indicated, they don't become "learned" until you actually improve your process.  I've been in organizations where we've held a retrospective, sometimes called a post mortem or "lessons learned" session, which resulted in a list of really good process improvement suggestions.  Always one to cause trouble, I then asked if the client had any similar documents from four or five years ago.  Comparing the documents, we've often discovered significant overlap between the lists.
7. Keep the real goal in mind. My experience has been that software processes, when applied intelligently, increase the productivity of developers. My experience has also been that when processes are applied less than intelligently, or when the paper pushers have too much influence within an organization, processes can also decrease your productivity. Organizations that keep the end goal in mind – that of developing, maintaining, and supporting software that fulfills the needs of their user community – will be successful with implementing software processes. Those that follow processes simply for the sake of doing so are likely to fail.
8. Recognize that the fundamentals remain the same, the details vary. Contrary to popular belief, the fundamentals of software development have been known for many years.  You need to perform requirements engineering.  You need to model.  You need to write code.  You need to test.  You need to perform change control.  You get the picture.  Every successful software organization will have a similar set of processes but the way that your organization brings them in and how they implement them will differ.  Your requirements process may be slightly different than your competitors, but you will both have one that will generally do the same sort of thing.
9. You need more than one process.  You wouldn't run a project team of thirty people the same way that you would a team of three people.  Nor would you run an outsourcing project the same way that you're run a project developed by a co-located team.  Nor would you run a data warehouse project the same way that you'd run a .NET application.  You need different processes, or at least different flavors of your process, for different situations.  Use the right process for the job.
10. Run a trailblazer project to validate your new processes. Regardless of how well you define a process, no process is perfect.  Test your new software process using a trailblazer/pilit project, one that is given the extra resources required to try new techniques and to update them appropriately. 
11. Treat process improvement like a project.  Have an experienced project manager, ideally someone with experience in both process-oriented and object-oriented development. Define the requirements for your processes, model them, implement them, test them with a trailblazer project, and then improve the processes.
12. Improve your processes in priority order.  The reality of process improvement is that you cannot make all of the changes that you want to immediately; it is simply too great a change for your organization to absorb at once. This is why we have efforts such as the Software Engineering Institute’s (SEI’s) Capability Maturity Model Integrated (CMMI) efforts and the Software Process Improvement Capability Determination (SPICE) efforts of the International Standards Organization (ISO). Both of these organizations suggest that you prioritize the process improvements that your organization needs to make, expect that it will take several years to make the needed changes, and expect that you will experience difficulties while doing so. There are five maturity levels in the CMMI for a reason: you need to progress in order from level one to level two to level three and so on.  The implication is that by knowing which aspects of a software process map to which CMM maturity levels you have a rough idea of the order in which you should introduce those processes to your staff.  Experience shows that organizations that try to make immediate, large-scale process changes are likely to fail doing so. The reality is that it takes time, often several years, to permanently improve the productivity of your software development efforts. There is not a simple, quick fix to your problems. 
13. Communicate your plan.  It is essential that you let others know what are you doing, why are you doing it, the business case for it, success stories, etc. Keeping them informed on how things are going, even if you are encountering difficulties, will help get them (and keep them) on board. There are various options for this: a newsletter, a web site, periodic emails to key personnel, etc. Trumpet your successes and share your lessons learned with the appropriate people.
14. Accept that the big picture is overwhelming.  Because of the complex nature of software development most developers specialize in one aspect of it and focus solely on that.  This becomes a problem for organizations that wish to tailor a software process for their exact needs because when they put the individual pieces together the overall process becomes very large.  For example, the Rational Unified Process (RUP) is over 3,000 HTML pages in size, and it is only a development process.  Once developers see how large your organization’s software process is they often go into denial, claiming that you can not possibly achieve your goals.  Yet when you ask an individual which part of their process they can simplify they’ll often balk at the idea.  An alternative approach might be something such as the Agile Unified Process (AUP), which is a bit smaller (it's around 30 HTML pages).
15. Democracies do not always work, nor do dictatorships.  Organizations that wish to reach consensus regarding their software process tend to flounder. You’ll never achieve complete agreement on how things should be done, although organizations that dictate processes from above tend to fail as well.  Effective process improvement efforts seek consensus at some points and dictate things at other points.
16. Identify the consumers and suppliers for each process.  Every process has inputs and outputs, and you need to ensure that there is a supplier for each input and a consumer for each output.  Fundamentally, if nobody is going to use an artifact that is produced by a given process then why bother producing it?  You also need to look at collections of processes to see if the artifacts that they produce add value in combination.
17. Defining a process is the easy part. Many organizations are very successful at defining a software process, often producing binders (or web pages) of documentation.  However, when I've revisited these organizations a few months after introducing a new process it will be all but forgotten.  Getting people to accept your new process, and making the changes that go along with it, will take significant time and effort to accomplish.  Writing a process is the easy part, following it is the hard part.
18. Introduce a Software Engineering Process Group (SEPG) to your organization. The sole responsibility of your SEPG is to support the definition and improvement of your organization’s software process. The SEPG should be kept small – as a rule of thumb, we suggest one SEPG member for every one hundred developers in your organization.  SEPG efforts are a component of the EUP's Software Process Improvement (SPI) discipline.
19. Staff your SEPG with actual practitioners.  The people who best understand how to develop software are the people who are very good at developing software.  Yes, that sounds blindingly obvious, but what isn't obvious is that they are usually the best ones suited to define your software process.  Try to staff your SEPG mostly with current practitioners, people who are now managers but had did some COBOL programming 20 years ago are often poor candidates, although include some people with a process background to ensure that they're not reinventing the wheel.
20. Reuse existing process materials.  There is a wealth of process materials out there, you very likely don't need to write your own.
21. Avoid “fire hazard processes". A common mistake is to produce volumes of documentation describing your processes. Your goal is simply to describe your process materials to such a level that they can be given to a professional skilled in the techniques of that process so they can work the processes appropriately.
22. Adopt processes because they make sense.  If a process makes sense to you, and you believe it will add value to your effort, then adopt it.  Otherwise, do not.
23. Hold everyone responsible for process improvement. Senior management must be willing to actively support and sustain process improvement, project managers must be held responsible for ensuring that their teams follow the defined processes, and developers must be held responsible for learning and then following the processes. This is often a difficult task because senior management often demands immediate results, whereas process improvement often takes years. Project managers resent diverting scarce resources from their projects, and developers often resent being told how to do their jobs.
24. Bring in an expert to advise you. Process improvement is a complex and difficult endeavor, one for which you are likely to need help to accomplish. You can increase your chance of success by bringing in a consultant who has both a process background and an OO development background – someone who has been actively involved in a process improvement program and who has worked on large-scale, mission-critical software development projects using OO technology. 
25. Do not think that everyone is on board. There is likely to be a small core of people within your organization who do not want to use object technology for large, mission-critical projects, and these people will actively undermine your efforts. You need to identify these dissenters and work together with them to help them see the advantages of working with object technology and of following a set of defined process patterns to help in the development OO software.
26. A fool with a process is still a fool. For your organization to be successful with a software process your software professionals will need to understand the processes, the concepts, the techniques, and the problem domain. Implementing a new process in your organization involves more than going out and purchasing a couple of new books and development tools.
27. Develop a user guide for your process. You can make it easy for your staff to learn your chosen processes by providing a well-written overview of your process as it is to be implemented in your organization.  In fact, this may be all the process material that you need.
28. Have patience. Progress will be slow at first, slower than you hoped or expected. Introducing a software process into an organization takes time – the required culture shift often takes years to complete.
29. Don’t flounder in bureaucratic requirements.  Too many process efforts run aground because of preconceptions forced on them by senior management, an overly burdensome documentation and review process, or unrealistic requirements to achieve consensus.
30. Define your process early.  The longer you leave process definition the bigger the mess you will have to clean up.  Without direction, developers will typically go and do what they think is right, the only problem being that each person has their own idea of what “right” is.

Grab Bag: Android, JavaFX, and the Allure of Software Engineering

There have been a few recent online articles and posts that I think deserve mention here. These are related to Android being good for Java, praise for the field of software engineering, and a sense of what Java developers think of JavaFX.

Software Engineering: High Pay, Low Stress?

A recent Yahoo! Finance posting of a Investopedia article (Five High-Paying, Low-Stress Jobs) list software engineering as one of their five jobs with high pay and relatively low stress. Some of us may not agree with the stress part, but it is not going out on a limb to say most of us do have less stress than a combat soldier (referenced in the article as an example of low pay and high stress). Under "Computer Software Engineer," the article states, "many software engineers can work from home, since their jobs can be done from practically anywhere. Software engineers also bring home steep salaries, normally ranging between $54,000-130,000 a year. There's nothing nerdy about that."

Another position closely related to software development also made this list of five professions proposed to be high pay and low stress: the technical writer. The other three careers on this list are civil engineer, physical therapist, and massage therapist.

Android: Bringing non-Java Developers to the Java Fold

One of the effects of the rapid rising popularity of Android-based telephones is the new entrants into Java's ecosystem of developers from non-Java environments. For example, the author of the blog post Android Development - Debugging Your App starts that post with the sentence clauses, "Coming from a Windows environment, specifically the .NET space," and then goes on to talk about debugging in Eclipse. 

The significance of this, of course, is that a whole new group of developers with little or no Java experience are now essentially working with Java itself as they develop Android applications and are using tools of the Java ecosystem such as Eclipse. Java may have originally been targeted at the web browser (applets) and may have in recent years become known as a technology for the enterprise space, but now it appears that it could be the Android-based handsets that bring standard Java (but not Java ME nor JavaFX) a growing base of users. Who would have predicted this before Android?

Java Developers on the Future of JavaFX

A recent Java.net poll asked the question, "Will JavaFX ultimately become a widely used rich client technology?" None of us have a crystal ball and these polls are obviously non-scientific, but I thought the responses were pretty inline with my own opinions based on talking to other Java developers about JavaFX. The respondents seemed to really consider the issue and provide a fair personal assessment. There were also several good comments added.

To the question of whether JavaFX will become widely used as a rich client technology, well over half of the nearly 370 responses were either flat-out "No" (18%) or the little less sure "Probably Not" (a whopping 40%!). About 16% of the responses were the tepid "Maybe" while about the same percentage were more positive and answered either "It's already widely used" (2%) or the much more realistic "The Version 1.3 Improvements Make it Likely" (14%). I don't see how anyone can think that JavaFX is widely used currently (unless the interpretation of "widely used" differs significantly from mine) and the results show that few legitimately believe that to be the case.

There are several observations from this poll. First, JavaFX still has more people thinking it won't become a widely used rich client technology than those who think it will. Second, I think this poll shows once again that the Java development community (or at least the members of the community who read Java.net and participate in the polls) are cognizant of what's happening around them. Third, the comments on this poll are really worth reading. I think they sum up pretty well some of the major concerns the majority of Java developers who think about rich client technologies have about JavaFX.

Monday, May 10, 2010

Online Resources: Android Development, Future of Java, Careers in Software Development

This was another week in which I ran across several blog posts and articles that I thought was particularly interesting and relevant. In this post, I reference these and quickly add my own thoughts on the various subjects. The topics covered by these posts I am referencing are quite diverse, but some common themes do underlie most of them. The individual topics covered include Android development, more on the future of Java, some "current Java" posts, and some insightful posts of software development career development.

Android Development

I recently upgraded to a Droid and have been more interested in Android ever since. There were several reasons for me choosing Droid, one of which was its Android SDK and the ability to leverage my Java experience in Android development as a hobby.

There have been several recent interesting posts on Android development. Besides the obvious sources of information on Android development such as the Android Developers site (including SDK information, The Developer's Guide, the SDK API/Reference, and the Android Developers Blog), there are nice community-oriented sites as well. Android Development Matters is one such site where various articles, posts, and forum messages related to Android development are all collected in one location.

Tim Bray is a prolific blogger and having him on the Android team has led to an influx of Android-related information. For example, his latest post on the Android Developers Blog is called Be Careful with Content Providers and warns Android developers to use undocumented content providers to learn from, but to not base their applications on these. Based on his comments, these undocumented content providers sound similar to classes and packages that Sun included in its Java SDK releases to get things done internally, but did not want developers using directly. Like these Sun examples, the Android internal content providers could change or be dropped at any time.

Although I partially selected Droid because of my interest in creating Android applications at a hobbyist level and although I purchased a book on Android development, I haven't actually started developing my first Android application yet. This in mind, it was nice to read a very quick summary of what one does to create an Android application in Team Pi's A Step-by-Step Guide to Write Your Own Android App. That extremely concise summary boils down the essence of writing an Android application, but for just a little more investment of time, one can go to the original source of this information referenced at the end of the post: How to Write Your First Google Android Application. Of course, the Android Developers Guide section on Application Fundamentals has provides nice introductory information.

In Is the Android truly open source?, Amy Vernon acknowledges that Android "is indeed more open than theiPhone," but is then critical Google for not being as open to outside decisions as they could be. I'm not sure if the author realizes that some of the most successful open source projects have been this way for some time now. SpringSource heavily controls the vision and future of the open source Spring Framework and Sun heavily controlled the decisions related to open source projects such as GlassFish, NetBeans, and so forth. IBM has had similar influence in the earlier years of Eclipse development. Other examples include Google's support of several projects including the Google Web Toolkit and Adobe's sponsoring and guidance of Flex. Even theApache Software Foundation provides similar guidance and vision for its projects.

Most of us like to think of open source projects as being more than just source that we can view and possibly modify for our own needs. We like to think of the community providing input and coming up with the best results. This has even worked well in some limited cases. However, many of the successful open source projects (including those I just mentioned) seem to have benefited from a single vision of a controlling organization (be that SpringSource, Sun, IBM, Oracle, Apache Software Foundation, etc.). In even more practical terms, organizations like SpringSource and Sun have contributed substantial resources to these projects. Without these contributions, these projects would be nowhere near where they are today. Most of us know the disaster that often follows "designed by committee" (EJB 1.x and 2.x are great examples) and having a single guide for an open source project seems to be a common characteristic of many successful open source projects.

Although I believe that Vernon unfairly minimizes (even as she acknowledges its existence) the gap in "openness" between Android and iPhone, I think one of her statements is particularly important for all developers to remember: "I'm not a developer, so as long as the phone does what I want/need it to, I'm good with it." Too many developers waste time and creative energy arguing over the merits of their favorite operating system, their favorite web browser, their favorite RIA technology (Flash versus HTML5 and Apple versus Flash being among the latest rounds), etc. The sometimes difficult to swallow fact of the matter is that developers' preferences are secondary to the preferences of end users and clients. They don't care how it's implemented as long as it does what they want. No matter how cool or nice a new technology is, it won't necessarily win unless it brings noticeable value to the end user. In Android's case, the end user still typically doesn't care that the development behind Android is more open than it is behind iPhone. However, this difference in openness may ultimately help Android in the sense that more developers will be willing to build their ideas into viable applications on a more open system.

More on the Future of Java

A week ago, I posted a similar post to this one in which I referenced and discussed several posts from the blogosphere that were of particular interest to me. Many of these were related to discussions about the "future of Java." Just after posting that collection, I ran into the insightful post "Java Post Mortem with Gilad Bracha" that summarized two presentations by Bracha at JAX.de 2010. I like this post for a couple reasons. First, it is a nice summary and analysis of Bracha's main points. Second, I think the points are insightful. These include points such as "Java is going to stay but it is going to stay where you don’t want to look" and "Complicated is not a sign that you’re clever. It is a sign that you failed." This summary is well articulated and worth the small investment of time required to read it.

Joseph D. Darcy posted Project Coin: Multi-catch and final Rethrow, a post that looks at the exception handling improvements coming to JDK 7. Based on the comments on this post, the "final" portion seems the most confusing and controversial. Darcy's current (most recent post as of this writing) is Draft of Restarted "OpenJDK Developers' Guide" available for discussion and is specific to JDK 7 as well.

Jens Schauder's post The Question Isn't What is Going on at Oracle and Sun outlines some warning signs to watch for that indicate "that Java is turning into just another kind of COBOL." Schauder points out some ways to transition to other languages when it is time to actively move to languages other than Java if you have not done so already.

Back to Today's Java

Although reading about the future features of Java can be exciting, it is often more practical to learn about what we can do today and to learn from each others' experiences. Along these lines, I found the post How we solved – GC every 1 minute on Tomcat to be interesting. In this post, Sumit Pal discusses the non-standard -XX:+DisableExplicitGC option for the HotSpot JVM. The reader feedback is helpful and adds some background details as well. When I blogged that more developers should write blogs, this was the type of post I had in mind.

In Annotation or Not, the post's author enters the debate regarding when it is appropriate to use and not to use Java annotations. I think most of us welcome annotations to a certain degree and the main part of the controversy now seems to surround what is appropriate for annotations and what is not appropriate for annotations. As I discussed in the article Basic JPA Best Practices, I like how JPA allows you to use annotations but override them via external (XML) configuration as needed. 

Software Development Career Development

There were two online resources this past week that I thought were particularly thought-provoking in the area of career development for software developers. In the post 10 Ways to Suck at Programming, Donnie Garvichdocuments ten things that "are really just things that every good programmer should already know to avoid." Among these ten things, a few of my favorites are "Never, ever remove functionality," "Document NOTHING," and "Catch all errors -- and do nothing with them." These and several others on his list were all too familiar for me (because of others' misbehaviors, of course). As with many of the best posts, the reader comments and feedback messages were also generally useful and interesting and included some additional items that could have made this list.

I have blogged before about my appreciation for posts that require the poster to sacrifice personal pride to provide a lesson from which we all benefit. This happened for me this week in the reddit programming postcalled I am now practically unemployable by everything I read. Any advice? Although this is somewhat anonymous (its author is unemployed58), it is still admirable that this author was willing to lay some personal career details out there. This post is a reminder that software developers need to stay current. It's a little frightening, though, that this author has stayed current to a degree, at least at the hobbyist level, but has still found himself unemployed for two years.

I often think developers waste a lot of time chasing fads because of dysfunctional motivators such as resume-driven development, the magpie effect, and so on, but this post is a reminder that there are problems on the other end (never doing anything new or different) as well. The post's author ends with, "I apologize for the rant just feeling a little frustrated today." I don't think there's any need for an apology. In fact, I appreciate the fact that this was posted and can be a reminder for all of us. Some of the feedback comments on this post are also useful in terms of ideas for the original poster that might work for all of us to reduce the chance of ending up in that situation and to deal with that if/when it does occur.

In Programmer Tip: Work Less, Stay Focused And Say No To Random Meaningless Slogging, Rajiv Popat points out the need for most developers to creatively solve problems in reasonable amounts of time rather than slogging away for 14 hour days (perhaps a dialect of presenteeism?).

Conclusion

I cannot come even close to reading all the content related to software development that comes out online each week that looks interesting to me. However, the resources that I referenced in this post are ones that managed to grab my attention amid the noise and bustle of the blogosphere and which I can wholeheartedly recommend for busy developers to invest time in reading if the covered topic is of personal interest.

[Source]