Emacs Script to Fold Text

Quite often I need to fold the contents of large text files at certain character boundaries. On my Mac, I can drop to the CLI and execute something like:

fold -w 80 my_text_file.txt > formatted_text_file.txt

This works well, but not on my Windows VM. Since I use Emacs everywhere, I thought it would make sense to have an Elisp function available in Emacs to do the exact same thing. Here is the source for that function:

(defun fold-text (char-count)
  (interactive "n")
  (setq counter 0)
  (while (< counter (point-max))
    (forward-char char-count)
    (insert "\n")
    (setq counter (+ counter char-count))
  )
)

(This script is also on Github here.)

Right now, I have this function listed in my .emacs file so it is available to me when I open Emacs.

Powershell Script Commands to Start and Stop Services

I don't do a lot of Powershell programming myself, but my company uses it quite a lot for automation.  We have several WCF web services that need to be running to support our web site, and it is a pain tracking them down and starting/stopping them in my local development environment.  I found a few handy commands for doing this in Powershell, and wanted to capture them so that I can easily find them again if necessary.

The following command gets a list of services, and starts any of them that are currently stopped.

get-service <comma-separated list of services> | where {$_.status -eq 'stopped'} | start-service -pass

The following command does the opposite; it stops any of the services that are currently running.

get-service <comma-separated list of services> | where {$_.status -eq 'running'} | stop-service -pass 

Continuous Integration for the Win!

Recently I worked on a minor integration between our primary web tool and Salesforce.  I used TDD to drive the code as much as possible, and the tests passed on my machine.  My team has a nightly build that compiles and runs unit tests on all of our code that is currently in flight.  A couple of days ago, the nightly build failed on a unit test that I created.

As a diligent developer, I checked out the branch that is used for the build, recompiled, and ran tests.  Everything worked!  It must be the build box, I told myself.  A few other tests were failing for unknown reasons, so the team was rebooting the build box yesterday.  Today, my test is still failing.

Again, being the diligent developer, I looked at the code that was failing.  This time, I noticed a flaw in the code.  I had basically missed an entire test case in a method I created.  I'm not exactly sure why the test didn't fail on my local workstation, but it did fail on the build box.  Without continuous integration, I would not have found this issue until the code was released to production.

Continuous Integration for the win!

Inspired by Google

I've started reading the book "How Google Works" by Eric Schmidt and Jonathan Rosenberg.  I am only in the first chapter, but it already has me thinking.

The first chapter discusses establishing the culture at Google.  In the chapter, the authors reference the founders' letter that was included in the IPO prospectus in 2004.  I read most of this letter, and it is different!

I'm not a business person and I'm not familiar with IPO literature.  Despite that, I found this letter wonderful!  It clearly states that the founders are trying to establish something different, they know it, and they are going to continue to do just that.  If investors wanted to invest, they could, but on Google's terms.  It's hard not to root for Google after reading that letter!

The In-Between Time

Within a year of my first agile project, there was a shift in leadership in the IT and software development organizations.  This leadership didn't fully understand or buy into agile development, so the implementation started to deteriorate.  At the same time, many of the advocates of agile development began leaving for other companies, so I found myself as the lone voice for the development practices and methodologies I had come to love.

Many people would probably ask why I didn't leave too, and it would be a fair question.  I liked the company and most of the people who worked with me, and I thought I would be able to push the organization back to agile practices.  I tried to stick it out and fight for all the right things.  Because of my tenure with the company and the projects I had been involved in, I knew the company and its business pretty well.  This experience gave my voice a little weight with the development teams, so I would encourage things like unit testing and small releases when opportunities presented themselves.

During this time, many new developers to the team would come to me for help.  As often as I could, I would try to sit side-by-side with them to work through issues, discuss design, and help them grow in their skills.  I learned how to adjust my communication to deliver ideas to different audiences*.  I also learned how to communicate new technologies and technical concepts to developers.  Even though we weren't following an agile methodology, I was growing and improving.

The company got into a mindset that it wanted to buy software to handle many of the big projects, and use custom software development to integrate the larger packages with each other.  I found myself doing a lot of maintenance work and being assigned to integration projects.  The integration projects were OK, but because of the personnel assignments, I wasn't heavily utilized.  The maintenance work was good because I exercised my unit testing muscles, but they didn't offer a lot of growth in new technologies.  As much as I liked the company and what it did, I progressed to the realization that I wasn't growing as much as I could be.

Even though I wasn't immersed in agile practices, I learned and developed quite a bit.  Skills such as communication, mentoring, unit testing, integration testing, quality testing, and learning the business would become crucial to success at my next company.

* This is still an area of improvement for me.

My First Agile Project

My first agile project was a re-write of an existing system.  The existing system was written in an early version of Java 1 and morphed as time passed.  It was a desktop-based application.  This re-write project was going to go through a full requirements gathering phase, design the application for scale, integrate it into the existing ERP system, and put it on a newer Java 1.2 system.

I joined the project part-way through the requirements gathering, and participated in many of those meetings.  These meetings were quite often contentious.  Many people had many opinions about what the new system should do and how it should do it.  Most of the people from the IT team were worried about the project.  The senior architect suggested that we use a new approach called Extreme Programming to deliver the system, hoping that the new approach would address many of the concerns.  I eagerly read the first Extreme Programming book, and got very excited.  The author spoke directly to all of the problems I encountered during my first internally-focused project, and his suggested approach made a lot of sense.  We were able to convince our management to let us try it.

We set up an area for the project team to work.  It contained open tables with shared computers.  Everything was arranged to make it easier to do paired programming.  The machines were configured identically so that it was easy to move around.  There were about six developers assigned to the project, along with a DBA, project manager, and architect.  We also identified a business user that would be available to test the system and answer questions.  With everything in place, we jumped into the Extreme Programming approach.

I don't remember how we prioritized the requirements, but we had a list of stuff to attack in order.  At every iteration boundary, the group would gather together with flip charts for planning.  We would write a feature/requirement at the top of the flip chart, talk through the tasks needed to accomplish it, and put estimates to the tasks.  We hung the completed sheets on the walls around our meeting area.  After several requirements had been planned, we picked what we thought we could get done in an iteration.  Those charts were moved to the walls around the programming area for the team to see.

Every morning the team met for stand-up, and talked through who would work on what task.  If there were any major roadblocks we talked about them, and tried to align the pairs to knock out the road blocks.  If there wasn't a particular pairing necessary for the tasks at hand, we picked pairs based on who was available and who had a task, and started our day.

The pairs worked side-by-side in the pairing area.  The keyboards and mice would move back and forth as pairs alternated coding, and if a pair got stuck, they would ask another pair for help.  Coding went fairly smoothly and efficiently.  Occasionally some personalities would clash, but either the project manager or architect would help defuse the conflict.  This was one of my favorite times writing code because it was productive, efficient, and the camaraderie was great!  Our progress through an iteration was tracked with burndown charts plotted on a big flip chart on the wall.

As features/requirements were completed, we brought the business user over to test the features.  Any identified bugs were addressed right away, and the user would test again.  We typically brought the business user over as features were completed; we didn't wait until the end of the iteration.

This project progressed well until we came close to a busy season in the company where the original tool was used heavily.  The company wanted to use the new tool for the upcoming busy season, which pushed us to work longer hours and aggressively trim scope.  Ultimately, we delivered the first version of the new system to the team that needed it most for the busy season, and brought other teams on board over the coming months.

Being a first agile project was difficult for a few reasons.  First, the rest of the company didn't understand the agile approach, and put a lot of pressure on the team to do things differently.  Second, the team was learning a new approach, which made it difficult to communicate with the rest of the company and each other.  Lastly, some of the team members hadn't bought into all of the Extreme Programming practices (most notably unit testing), and that difference sometimes caused more friction on the team than was necessary.

I view this project as a success!  The company got a system delivered when they needed it.  The applicaiton was very well designed and well written.  The team of developers gelled pretty well, and continue to stay in touch with each other even though everyone moved on from that company.  It also solidified for me the importance of culture within a development team, as well as how many of the agile practices influence the quality of software.

Now it was time to mature our practices and move them forward.

Becoming an Agile Practioner

As I have brought new people on to my team and taught them agile development, I have either told stories about my evolution into agile development, or reflected on it.  I keep thinking that it would be a good idea to document that evolution before the details become any fuzzier than they already are.  So, that's what I'm going to do.  This first post lays out my background and what led to me getting introduced to agile development.  Future posts will document my practice of and progress through agile techniques.

Backstory

I started my career in software development creating imaging systems for customers.  The team I was on consisted of software developers and system/network administrators.  We took on discreet projects setting up, maintaining, and creating imaging systems based on software provided by a vendor.  Some of our projects were nothing more than equipment setup and installation, while others involved complex software systems that we developed.

All of our projects implemented a version of the waterfall methodology.  There would be a requirements gathering phase that resulted in a contractual statement of work.  The tech team would then design the system based on the requirements, create it, test it, and when possible, test it with the users before delivery.  Some members of the tech team would then deliver the system, which often involved hardware set up as well as software installation and configuration.  The project "leader" would then take the customers through a formal User Acceptance Test and get an official sign-off.  At this point, the project was in a maintenance phase.

The majority of projects that I was involved in using this approach were highly successful.  Since this was my first job, it was the only approach I knew.

After a couple of years on this team, I would quite often be involved in leading these projects and seeing them through to completion.  I knew the software and approach very well, and I was enjoying success as a result.

While on a trip to a client sight, my boss informed me that he was leaving the company to start his own business.  The resulting transition moved me onto a team focused on internal software development projects using a completely different technology stack.  Needless to say I was a bit lost!

I was given a few small projects to tackle, and I struggled with them.  Not only was I trying to learn a new technology, I was also trying to understand what the team was trying to accomplish and for what reasons.  With so much in flux, I needed to establish some consistency to maintain my sanity.  I turned to the tried-and-true methodology for delivering software that I had used previously.

At first, the waterfall approach seemed to work well.  I was able to get a definition of requirements, and could design the system.  Myself and another developer from the previous team worked to create the system in question, and eagerly set up a User Acceptance Test to show it off.  This is the point where things came off the rails.

The stakeholder liked what we had done, but added several additional requirements during the test.  This was not uncommon, so we satisfied the requests and re-did the test.  Again, things weren't quite right.  We did more work.  We showed it off again.  We went through several of these cycles, eventually getting the system to a point where it could go into production.  We never had the same sense of accomplishment that we had with our previous waterfall projects.

It felt like the tried-and-true methodology that I had come to rely on had utterly failed, and I could not stop analyzing what I did wrong.  I struggled to contain scope and keep the internal stakeholder pinned to a set of requirements.  The code drifted out from under us as the scope moved.  Worst of all, we didn't have the great sense of accomplishment from a truly successful User Acceptance Test.

I struggled most with two aspects of the project.  First, I could not control scope for the life of me.  Without a formal contract of any kind, or any leverage with a VP of the company, scope moved every time the VP saw a demonstration.  Second, I found it extremely difficult to design and code a system using a new technology stack under the confines of a waterfall approach.  I didn't feel like I had the leeway I needed to experiment and learn what needed to be done.

At this point, I turned to an experienced software developer in the company for help.  The developer introduced me to the original Extreme Programming book, and thus began my journey as an agile software developer.