Tag: project management

My Current Windows Development Machine Software Stack

I recently did a clean install of Windows 7 64-bit.  It had been a really long time since I listed the current tools, SDKs, and frameworks that I’ve been using.  Thus here’s my entourage of software that I use on a regular basis that is installed on my primary development machines.

Basic Software & System OS

Administration Utilities

Themes & Such

In addition to these packages of software another as important, if not more important to my day-to-day software development includes these software services and cloud hosting services.

SaaS, PaaS, and IaaS

Software I will be adding to the stack within the next few days, weeks, and months.

Waterfall vs. Agile

Before reading this you should know what the Agile Manifesto is and the Agile Principles are.

I’ve seen it on more than one project in my career and it always seems to happen.  Agile rarely gets credit in this scenario.  People rarely learn what was and was not effective on the project in this scenario.  Those that are Agile Practitioners that know what a truly fast paced, effective, high quality, and successful software project can be know.  What I’d like to know though, especially from those that have successfully dealt with the “Must have big design up front (BDUF) headaches” and transitioned those people to a more Agile style approach.

The scenario generally starts like this…

A project is green-lighted for whatever reason.  Often with some high level manager determining that a project will save or make $X amount of money.  The project is poorly defined or simply not defined at all.  The stakeholders, clients, or others that would prospectively use the software are nowhere to be found and unidentified by management.  There are at least a half dozen external dependencies the project must have completed.  (Take Note Upper Management & Executives:  Six Sigma/Lean Processes can help at this level dramatically)

Waterfall Approach

In a waterfall approach all of these things will have to be documented and nothing initially gets developed.  The people writing the documents, often some sort of business analyst, is forced to basically make up whatever they can come up with.  In addition to that and hypothesis is derived from thin air and someone starts to come up with a more functional, technical, or even concrete UML design documentation.  To summarize, in a waterfall approach a whole bunch of people start documenting all sorts of things about this theoretical application software.  A 6th grader would study this and say, “so they write a bunch of lies right?”

When the actual concrete ideas come to fruition, long hours of the famous death march approach usually start.  Sometimes more and more people are thrown at the application in hopes that somehow it will speed things up, but in reality as a seasoned software developer knows, it only slows them down.  Other issues very common with this approach are horrifying low code quality, a lack of tests, missing ability to regression test, no verification of what done truly means, and a whole host of known issues.

Agile Approach

An Agile approach on the other hand would start finding the clients and consumers of the theoretical software.  These people would be engaged and some paper prototypes or other initial sketches of what the software might do are created.  Maybe sketchflow or some other software is used to create some rapid prototypes to give the clients an idea of what the software would look like and what it might do.  The clients start giving feedback and a more concrete idea is formed around this theoretical software upper management has dictated.  Initial tests and code are written and put into a continuous integration process, with an end product being dropped every few days or weeks.  A 6th grader would study this and say, “you’re building software and having fun?”

What Happens in the End, IF the Waterfall Project is Successful

There seems to be two resolutions that I’ve found that allow Waterfall to actually be successful.  The first is that the project forgoes the charade of Waterfall and starts implementation of more Agile ideals and processes immediately.  This cleans up things and improves morale, all while getting the project back on track.  The second solution is that development/engineering determines they’ll do Agile anyway, and up manage the management.  Management thinks they have a successful Waterfall Project when in reality the proactive developers/programmers took it upon themselves to assure success, and thus moved to an Agile ideals, process, and practices among themselves.

In Summary

These two different models are HUGELY disparate, and yet the aforementioned waterfall model approach is still heavily used.  I suspect, unfortunately, that it is primarily used at a majority of businesses (and especially Government).  Even if the business or Government pretends they’re doing Agile and calls their Waterfall Model Agile something another.  This is something else I’ve seen far too often.  This is a complete misrepresentation of what Agile Ideals and processes are.

The Questions

I’d like to know, what methods do you use to attack and remove the barriers caused by waterfall at large organizations?  Do you subvert the existing management infrastructure and just do things in a more Agile way regardless in order to succeed?  Are there any specific practices, techniques, or otherwise that help you align so that one can keep a project moving along quickly, all while avoiding the damage waterfall models do to the actual underpinning project, code quality, and other such items?

Please leave a comment or three.  🙂

Those People That We’re Always Looking For…

I’ve been rereading Joel Spolsky’s “Smart and Gets Things Done”.  His writing style is entertaining.  I’m not always in 100% agreement with the guy, but who ever agrees 100% with anyone right?  However, Joel has a ton of things that are smart, well thought out, and when one pays heed can really help out during the course of a software project.  Since I’ve been writing on this topic lately, I figured it would be a great idea to give this a read and maybe even add my two cents to a few of his passages.

I didn’t get very far and I had already found one bit that I wanted to elaborate on.  This part was in remark to hiring college interns and the fact that the best college students are often already good programmers.

“The good news about our field is that the really great programmers often started programming when they were ten years old.  And while everyone else their age was running around playing “soccer” (this is a game many kids who can’t program computers play that involves kicking a spherical object called a “ball” with their feet (I know, it sounds weird)), they were in their dad’s home office trying to get the Linux Kernal to compile.  Instead of chasing girls in the playground, they were getting into flamewards on Usenet about the utter depravity of programming languages that don’t implement Haskell-style stype inference.  Instead of starting a band in their garage, they were implementing a cool hack so that when their neighbor stole bandwidth over their open-access Wi-Fi point, all the images on the web appeared upside-down.  BWA HA HA HA HA!”

This got me thinking.  I’d like to find programmers who have started a band, chased the girls, played soccer, flipped the images, argued the Haskell points, compiled a Linux Kernal (or two or three), and more.  I don’t want the all exclusive nerd only programmer, because today they’re often not that useful on software projects.

When I’m looking for other developers to hire and work with I want a number of things.  The technical bits are of course important, very much so, but I want to work with developers who know about all sorts of things.  I want programmers that know why financial application development pays well and non-profit work doesn’t, I want them to know about the successes and losses of business endeavors within the software industry.  Most importantly, I want them to be personable, approachable, and interested in life beyond just hacking lines of code 24/7.  Nothing wrong with the later, but that is only helpful for about 20-40% of the time on a project.

Warren Buffet looks for the criteria of “integrity, intelligence, and energy”.  I’m curious, readers out there in reader land, when you’re looking to work with a team or hire a team member what do you look for?  What are some key indicators besides the white board coding questions and technical bits?

Software Project Baseline

There are multiple phases to a software project.  In this blog entry I would like to talk about and discuss (please leave a comment or two) what the basic things are that a software project needs to get started and prospectively move through development and on to a successful deployment.  The following is a short list of the key items that a small software project needs to move forward.

Core Ideas and Staff

  • The core idea must be available via a readily available resource.  This could be an individual such as an analyst, a customer, or other person.  Another option would be some written definition, detailing the high level concepts of what the application could do with avenues for determining more specific functionality as the project moves forward.
  • The appropriate leadership;  project manager, application architect, application designer, or other leads need to be available and have an understanding of how the project will be accomplished from a staffing level.
  • Appropriate staffing for engineers, user design experience, and others that will do the technical work.  These individuals would preferably know what the above stated core ideas are, be in continuous contact with the key stakeholder who lays out the core ideas, and be knowledgeable in the realm of the technology that will be used to build and deploy the software.
  • Project ideology and methodology needs to be clearly defined and explained to all members of the development team, user experience, customers, and anyone involved in the project.  This needs to be done shortly after the core idea is laid out.  This aspect of the project is basically the “strategy” or “game plan” that will dictate how the day to day operations of the project are performed.  Lean Agile with a proactive vs. reactive nature, SCRUM with a high level waterfall at the executive level, and others are examples of ideology and methodology.

Technical Bits

  • A development technology stack, or at least some of the main pieces (IDE, main programming language like Java or C#) needs to be identified to focus around.  This needs to be done early enough to determine appropriate staffing skill sets, but not too early as to derail the focus on the core ideas.
  • Appropriate machines, with at least basic operational software (It could be Linux with OpenOffice, Windows 7 with Office 2010, or simply an Internet enabled device running Google SaaS Office Apps).  These devices need to be made available before the start of the project for every staff member.

Summary and Questions

These are the basic things that I could think of at a very low level.  I am trying to create this list at a very simple and basic level.  In a future entry I will extend past this to what is needed from a practices point of view in more detail, and the same for the technical bits.  I would love to get any feedback on additional items for these lists.  Please leave a comment or three and help me out if you would.