One of the most frequently asked for attributes on a credit or job application is Job Title. As an independent business owner I have answered this question in multiple ways:

• Programmer
• Software Developer
• Software Engineer
• Architect
• CTO
• Coder
• President
• Jedi Master
• Etc...

The scary thing about this is there is no real way for a potential employer,  banker or client to certify what I say is legit. This is a fundamental issue with our industry. There is no way to verify whether a person is a quality software engineer or simply a charlatan. And for the record there are more of the latter than the former.

For the most part programmers like to think of software development as engineering. We like to compare ourselves to engineers with a capital E, construction managers, manufacturing process managers, etc. But do we really practice engineering ? What is the bar for calling yourself a software engineer?

I know for a fact that if I need an expert licensed plumber, electrician or ironworker I can take myself down to the local union hall and find someone that has gone from apprentice to journeyman over the course of many years.  And thanks to my friend Eric Anderson I learned that there is such a thing as a Professional Engineer. Here's the list of requirements for Professional Engineers as taken from the Wikipedia

1. Graduate with a degree from an accredited four-year university program in engineering.
2. Complete a standard Fundamentals of Engineering (FE) written examination, which tests applicants on breadth of understanding of basic engineering principles, and optionally some elements of an engineering specialty. Completion of the first two steps typically qualifies for certification in the U.S. as an Engineer-In-Training (EIT), sometimes also called an Engineer Intern (EI).^[5]
3. Accumulate a certain amount of engineering experience under the supervision of a P.E. In most states the requirement is four years, but in others the requirement is lower.
4. Complete a written Principles and Practice in Engineering ('PE') examination, testing the applicant's knowledge and skills in a chosen engineering discipline (mechanical, electrical, civil, for example), as well as engineering ethics.

For software engineering there is no similar accreditation process. Any Mort i.e (NOOB) with $500.00 and the ability to hit the keyboard with his/her forehead  can become a software engineer overnight.  "Yesterday I couldn't spell it. Now I are one". This has got to stop.

A few weeks ago I came across a commentary made by my friend Billy Hollis in Visual Studio Magazine Commentary: Is Agile Rock or Disco. In this commentary Billy mentions the following:

The Patterns and Practices group at Microsoft is heavily into agile development. Don Smith is in that group, and, at a conference last May, he said, "It's hard to do agile without really good developers." I've heard variations of the same thing said from others.

But not all developers are that good. Therefore, if Don is right, then agile isn't for everyone.

The second statement is the core problem we face. It raises the white flag of surrender to all the half ass coders out there. Why shouldn't we all strive to be good developers? Why is average acceptable? What does the author propose we do with the average programmer?

Because programmers are less than good (LTG) does he propose we have no process whatsoever? It's because of these LTG developers we need agile practices more not less. I want to point out something carefully at this point. It's agile practices... not agile! There is no push button template  you can use and whoosh you are an agile coder or development shop. Nope agile is a set of principles and practices.

Adopting agile principles is not quick or easy. It is a lifetime commitment that takes lots of study, practice, mentoring, and continuous education and improvement. There are lots of new terms, concepts and practices to examine, consider and implement. Every company and situation is different and there are a number of useful practices to adopt.

Agile Adoption

In the last year we have moves very heavily from our old RAD way of doing development to a more agile one.  Our goal in this process was to change how we design and develop software in a quality manner. These are the tools and practices we have adopted.

Shared State Source Control

The first practice we adopted was changing from a pessimistic style of source code control into a shared state source code control system. It made no sense to limit a source code file to a single developer (the default behavior of Visual Sourcesafe). We moved to Subversion. Subversion is an industry standard source code control system that's default behavior is multiple developers working on the same files and merging conflicts. 

Automated Builds

Another principle of agile we have adopted is that of automated builds. Another terms for this is Continuous Integration.  Whenever source code is committed to our repository an automated build fires off, checks out all the code, compiles it and runs a suite of automated tests.  Our goal is to find whether or not our code is in a Red (bad) state or Green (good) state. 

Test Driven Development and Design

Of all practices in agile I find this one to provide the most value.  Any software you build should be accompanied by a suite of tests to verify its long term quality and  integrity.  The ultimate goal of TDD is a good design.  While test driven development does not insure a good design your chances are better that your designs are more sound if they can be tested in an automated way.

I had a conversation with Scott Bellware and Chad Myers last night. We were discussing testing nomenclatures and Chad Developed this list of test types:

• Proofs  - Code performs as expected.
• Examples of Client Access (API testing) - API Proving with tests.
• Specification (BDD) - Documenting intent.
• Contract Enforcement/Change Confidence - Regression testing

As you can see these nomenclatures provide you with a confidence that your code will work as expected, has its intent documented and allows for long term changeability inherent in all software development.

Pair Programming and Mentoring

Union plumbers and electricians go through extensive apprenticeships before they are accepted  as journeymen. Software engineers should adopt similar practices. Pair programming facilitates knowledge transfer from master to apprentice,  mentor to student and in lots of cases from student to mentor. In the last year I have spent a lot of time discussing these practices with a number of different people I consider my mentors. My mentor list includes Scott Bellware, Jeremy Miller, Chad Myers, Jeffery Palermo and numerous others. These practices are not always obvious or simple so it is a good idea to have a network of mentors to rely on.

Adoption of Dependency Patterns

One aspect of building testable systems is reduction of  development friction. One way to introduce friction is to tightly couple processes together by allowing them to instantiate there own resources internally.  It may seem strange  but information hiding is not necessarily a good practice in the agile space. The concept behind dependency injection is this: if a component or method has a dependency on another class, then  that dependency should be passed (injected) into the consumer.  This give you untold flexibility when it  comes to configuring and reconfiguring your systems.

Daily Stand Ups

In agile development a common set of practices revolve around daily developer meetings also known as stand ups. Every day developers stand in a circle, stands at there desks or in the hallway and talk about two items:  what the did yesterday and what they plan on doing today. This  has the benefit of keeping all  developers in the loop and facilitating communication.

Small Iterations

We all know that estimating timelines on most software projects is a fools errand.  Software estimates follow share a common trait with metrological predictions the shorter the span or time the more accurate the estimate is likely to be. Agile practices acknowledge this as a core principle.  Your applications should be developed in short sprints.  At the end of each sprint there should be "show and tell" for the client that demonstrates the deliverables for that sprint. After the sprint and accompanying demo the next sprint should be planned. And its rinse lather repeat from there.

Conclusion

While not definitive this list is a good start to moving you or your development team closer to being professional software engineers. When you are evaluating a client, consultancy or even a potential employer consider the practices discussed in the list. 

Do you think your a great coder or do you think your development shop is top notch? I challenge you to prove it. Can you develop quality software that stands the test of time ? Do you have software you can modify with a high level of confidence that your modifications don't introduce software regressions? Can you repeat and improve on your successes? Do you have the processes in place that make this a possibility? When you can answer in the affirmative to some or all  of these questions you are closer to being a true software engineering shop.