Does X Make You Successful?

I was recently asked to complete a survey about Test Driven Development. After looking through the questions, I found that I couldn't really answer them.

1. In how many projects did you use TDD?
2. Was TDD successful in at least 50% of the projects?
3. Did TDD delay the release date of the projects?
4. Describe the advantages you realized after using TDD.
5. Describe the disadvantages you realized after using TDD.
6. Did the software maintenance decrease after using TDD?

The questions are fair questions, and the survey was put together by an engineering student (and I love that he is reaching out to people to ask about their experiences). The problem I had in trying to answer the questions is that it's hard to take a single practice (such at TDD) in isolation and credit success/failure/maintenance costs to that one thing.

Disclaimer
I'm not much of a TDDer myself. I'm a huge believer in unit testing, and I'm convinced that Unit Testing Makes Me Faster. But I'm more of a "test along side" developer, where I'm writing code and writing tests more-or-less together. I don't strictly follow the red-green-refactor cycle, and I don't mandate 100% code coverage in my projects.

Note: If you're curious about my unit testing talk, you can see a recording from Visual Studio Live! from last May.

You might ask why I have videos showing people how to do TDD if I don't use it widely myself. That's mostly environmental. Based on the types of applications I've been building and the environments I've been working in, TDD hasn't been a the the best fit (although I'm sure there are those who disagree with me). But I have seen TDD be an extremely useful tool in a lot of circumstances, so I want to encourage people to explore it and help them get over some of the roadblocks that might stop them.

Other Factors
The problem with trying to isolate success to any one practice (whether Agile, Scrum, TDD, CI/CD) is that there are always other factors that influence success or failure.

Failures
Specifically with regard to TDD, I've seen teams fail horribly using it. I was a bit outside of these groups, and TDD was not the cause of their issues. There were issues with the management not trusting the developers. There were issues of mandating tools and processes that the developers did not believe in. There were issues around team dynamics and trust.

So there were projects that failed while using TDD. But I would not attribute the failure to TDD.

Successes
On the other side, I have a good friend who is a huge TDD proponent. He has been very successful using it, and he helps other people understand it and be successful with it.

I also know a company with a very successful development department. They have several teams that all build code using TDD. But they also have good team dynamics, trust, and a learning mindset. They are always looking for ways to do things better, and they are not afraid to discard things that don't work in their environment.

Isolating Success
The gist of this is that it's really hard to isolate what makes us successful.

I've heard people say, "Once we went to CI/CD, we saw X improvement [in speed / cost / maintenance]." But it's really hard to credit that to Continuous Integration/Continuous Delivery only. That's because most teams are not ready to simply flip the CI/CD switch.

To get to the point where we can be successful with CI/CD, we need to have good automated testing in place, we need to have good source control, we need to have good branch/merge practices. Then we can get to automated deployments. So even if we can make our users happier once when we have CI/CD in place, our success is really attributable to the other factors as well.

Continuous Improvement
One thing that I emphasize when I'm encouraging people to include unit testing in their environment is that it takes time to learn something new. It's not something that we will be instantly productive with.

With any process, framework, library, or language, we go through 3 phases:

1. Learning the technical bits
   This is where we get the basics about how to install tools, what commands are available, and how to get things working from a technical standpoint.
2. Learning the best practices
   This is where we look for experience and advice from other people who have used this tool. We can see what worked for them and what didn't work. And this gives us a good place to start in our environment.
3. Learning how things fit in our environment
   This is where we see what works in our own world. The best practices that we picked up from other developers were things that worked well in their environment, but that doesn't mean they will work for us.

Once we get through phase 3, we can be really productive with this tool. We've figured out how it can really help us, and we're comfortable using is effectively. (And we may not get to phase 3 if we find that the tool really doesn't fit in our environment.)

There is No Silver Bullet
There is so single tool or practice that will make us successful. I've seen teams using Agile fail and I've seen teams using Agile succeed (and I won't get into the "you're doing it wrong" discussion here). I've seen teams using TDD fail, and I've seen teams using TDD succeed.

My biggest frustration was watching a group that was really broken. The management didn't trust their developers and so they tried to come up with the one process that would ensure that every project would be successful. But there is no silver bullet. And every 6 months, they would give up on what they were doing and try another process to ensure success. Over the course of years, I saw each of these processes fail.

There was nothing wrong with the practice or process they chose. And the practice was not the cause of the failure. We need to look beyond any particular practice and talk about what makes up a productive team.

Asking the Right Questions
Programming practices come and go. Programming languages come and go. Programming frameworks come and go. Each of these can be useful tools in the hands of good developers. And they can also be used to create complete disasters.

We need to think about the questions that we ask about any of these tools.

What problem is this tool designed to solve?
Do I have this problem?

There was a time in my career where I did an analysis of the MVVM design pattern, and determined that it was not appropriate for our environment. Of the 3 problems it was designed to solve, we had already solved 2 of those problems another way, and we didn't have the 3rd problem. Since then, I have used MVVM quite successfully in a lot of other environments. But we do need to stop and ask those questions.

So rather than asking if a particular tool or practice makes us successful, we should be asking "What problem is this tool designed to solve?" And of course, "Do I have this problem?"

Happy Coding!

More Organic Software: Escaping Into the Wild

A couple days ago, I wrote about how an application I wrote for myself escaped into the wild and became added value for the company. But I also had this happen with another piece of software that I wrote for myself. The way it grew organically based on business needs makes me think about how No Estimates can be appropriately applied in similar situations.

Working with Time Clocks
In addition to working with automated turnstiles, I also worked with the time clock system. Specifically, I worked with the time clock hardware and data collection. This was then transferred to the time tracking system (which was the "system of record" when it came to time tracking).

The time clocks worked with similar hardware as the turnstiles, and so I would check them every morning to make sure that the everything was online. Initially, I used a set of SQL scripts to check this, but as you can imagine, I ended up writing a little application to help me out with this.

This application had a drop-down box that listed all of the time clocks and a data grid to show the latest transactions. Again, I could easily scroll through the drop-down and see which time clocks were reporting data. This required a bit more thought, though -- some time clock locations were used more heavily than others. For example, the time clocks at the site entrances had a steady stream of transactions, but the time clocks that were in the maintenance shops were only used by a small group of people, so it was normal to have sporadic transactions.

Escaping into the Wild
The scheduling team would use the time tracking system throughout the day. They would make adjustments if someone clocked incorrectly (or forgot to clock in/out). And they would also check for "no shows" -- people who did not show up for a scheduled shift.

Because of this, the scheduling team was more dependent on having the data consistently sent to the time tracking system throughout the day.

One of the schedulers saw my application and said, "Can I have that?"

And the reason turned out to be pretty simple. If he saw a gap in the time tracking system, he could check to see if a particular time clock was off-line. If an employee regularly clocked in at the west entrance, he could check the 3 time clocks at that location to see if they were all reporting data.

If one of the time clocks appeared to be off-line, then the scheduler could contact my team to have it reset. This gave them better visibility to the system, and they knew that if a time clock was off-line, they would not necessarily mark "no shows" for people who normally clock at that location.

More Features
I think it's good when a business area asks for more features. It shows that they are thinking about the technology and data that we have provided to them and coming up with new ways to use it. So, I wasn't really surprised when I got a request for more features in the time clock viewer application.

We had security swipes at the entrances to the site. This would allow the security team to easily check that people were allowed to enter the property. The employees would swipe their card, and get a "go" or "no go" based on whether they were an active employee (cards would get automatically disabled if someone quit or was let go). But this also meant that people who needed to clock in had to swipe again at a time clock.

To streamline this process, we combined the security system and the time clocks. We used the time clock to collect the card swipe (either a bar code or RFID) and then pass the card information along to the security system for validation. This resulted in a single swipe for people who needed to clock in as well.

But there was a process issue: the employee would need to press the "Clock In" button the time clock before swiping his card. If you did not press the button, the security swipe would be processed and you would be allowed on property, but a time clock record would not be generated.

"I Forgot"
As you can imagine, when people do this everyday, sometimes they forget to push the button (as they are maybe rushing too quickly one day), or they think they pushed the button but it didn't register, or they simply forgot to check for the "clock in accepted" message that would normally display.

If someone forgot to clock in, the schedulers could manually add a record to the time tracking system. But because this was a common occurrence (especially when there are several thousand people clocking in throughout any particular day), the schedulers wanted a bit more information.

You see, some employees had figured out a way to game the system. If they got to the clocking location and found that they were 2 minutes late, they could "forget" to press the "Clock In" button and ask their scheduler to override it. This would mean they wouldn't get penalized for being late.

So the schedulers asked if there was a way for them to get the time clock data combined with the data from the security system. This way, they could look up an individual and see what time the security swipe went through. This would let them check to see if people were actually late when they came in, and it would allow them to separate the people who forgot to clock in from the people who "forgot" to clock in.

Business Changes - Things Get Complicated
Whenever you deal with time tracking, things get really complicated. There are federal and state regulations, there are company policies, and there are union rules -- all of which need to be followed.

One change that came about was the ability to clock in and out at your work location (instead of the property entrance). The reason is that it could take 10 to 15 minutes to get to your actual work location from the property entrance. You were supposed to be at your location and ready to work at your scheduled time, so having a time clock at the location would help better track that.

Unfortunately, the time tracking system didn't have this level of granularity. It kept track of "clock in" and "clock out", but not the particular time clock that was used.

So, we were asked to come up with some printable reports that could be used by the location managers based on the raw time clock data. These reports would allow a manager to see all of the clock transactions for employees in their area (based on their department identifier). The manager could double-check that their employees were clocking at the right locations, and they could coach employees who needed a reminder on procedures.

Later on, we extended the functionality of these reports to show "exceptions" -- such as people who clocked in but forgot to clock out, or for people who clocked in and out at different locations. This let the management teams focus on where specific problems lie.

And all of this helped the company comply with the various contractual rules and legal regulations that governed the time tracking of employees.

Wrap Up
So, here's another example of an application that grew organically as the business areas saw places where we could add value. And it's another good example of how No Estimates could work well in a changing environment.

And even though I've come up with some good examples of where No Estimates would be effective in projects I've worked on, I've also been thinking about some situations where it would not be a good choice. (I'll be writing about these soon.)

This doesn't bother me, though. No tool is perfect for every situation. I wouldn't expect that No Estimates would be a good choice for every situation, either. What's important is that we take a look at our current processes, determine what's working and what's not working, and look toward improving things where we can.

Happy Coding!

No Estimates: Development by Subscription

Last week, I spent a couple of days at Agile Open SoCal. It was a great time to talk about various issues and successes and get some great advice from other people who are in similar situations. There's a lot for me to process, and a couple of topics really stuck out.

One of these was No Estimates. I'll have to admit that I've been following this discussion from the sidelines. If you want to catch up on what No Estimates is, check out what Neil Killick and Woody Zuill have to say. I will not do the description justice, so you'll want to go to these guys who have been thinking about it for a long time.

I know Woody from the SoCal developer community, and I had a chance to sit down and talk to him a bit last week. (He's also known for showing the success his team has had with Mob Programming).

We Suck at Estimation
One of the basic truths is that we (as developers) suck at estimation. But that's not really a surprise. We are constantly being asked to do things that we've never done before.

An experienced cook will be able to tell you how long it will take a bake a cake. After all, he's done it a dozen times and knows what to expect. But for someone who's never baked a cake (like me), I would end up "padding the estimate" on how long it will take me. Is it because I don't know how to follow a recipe? No. It's because I'm working with unfamiliar tools -- I don't know exactly how to use the mixer or if I'm going to mess up a batch by over-mixing or under-mixing.

And this is true in software. Whenever I'm looking at a new project, it usually contains 4 things I've done before and 1 thing that's new to me. Now, I'm not completely ignorant of the technology (I've seen someone use the mixer), but I don't know what problems to expect (if you don't grease the bowl before you start, you won't get an even mixture).

I do not like to not deliver on my commitments -- meaning, I would rather over-estimate and deliver early than under-estimate and deliver late. The same is true in the rest of my life: I'd rather arrive at an event an hour early than 5 minutes late.

This means that I have a tendency to over-estimate:



I don't do this so that people will think of me as a miracle worker. I do this because I want to make sure I deliver on my commitments.

But this doesn't make my estimates any better than someone who under-estimates. In both cases, our estimates are wrong.

Eliminating Estimates
So, the idea of No Estimates is that we get rid of the estimation process. Instead of coming up with a huge project plan with lots of incorrect estimates (that end up compounding the problem), we focus on continually delivering small pieces of value.

I like the idea of this. And as a responsible developer, I think that it would work well for me and my development style -- I like to make my users happy, and I can best do that by constantly giving them features that make their jobs easier.

But I have been skeptical for a number of reasons. First, not all developers can work this way. There are some developers who would take advantage of the situation and slow down their delivery. There's no longer things like "story points" and "velocity" that measure productivity. And even though those measurements are probably wrong, people like to have something tangible to look at. The solution to this is to have managers who can keep track of productivity (in other ways) and know the capabilities and output of their teams.

Second, many companies cannot work this way due to their budgeting process. The financial systems are built around large projects and schedules. Marketing wants this and Sales wants that and Operations needs this other thing. So let's figure out how long each thing will take, how much our development team can handle at one time, and then prioritize everything. On top of that, money for the projects comes out of different buckets depending on whether it is a capital or expense project. I have no idea how to resolve this issue.

No Estimates is more of a subscription model for development. Instead of the business areas putting aside money for Project X that will cost $50,000 (maybe), the development team is funded on an on-going basis -- just like the other teams (finance, sales, operations, maintenance) that add value to the company.

The Business Areas Already Do This
I had a realization about this based on my experience: even though the company does not work this way, the business areas do.

I worked at a large company (20,000 people on site, 100,000 people in the division), and I built software for the various business areas based on what came down from project planning. And this was a hassle for many of the business areas. Sometimes a department just needed a small piece of functionality. It wasn't large enough to justify an entire project -- maybe just a report to collate data. And even if it were big enough, it probably would not be prioritized near the top of the list. So it may take a year or more to get it on the schedule.

The solution: Shadow IT. I don't know if there's an industry name for this phenomenon, but this is what we called it in our company. A department would have someone on staff who was more technical than most and probably good at something like Microsoft Access. This person would then build all of these small pieces of functionality that the department wanted to make their job easier.

So the business areas have already bought into the idea of development by subscription. They have decided that it was worthwhile to pay someone in their department to handle these types of things. And this Shadow IT person was paid out of the same budget as all of the other employees in the department.

(And this arrangement isn't all puppies and rainbows. Since the majority of the Shadow IT people did not have any formal technical training or experience, some of the projects would run into scaling issues or simply stop working when the data got too large. At this point, the systems were critical to the department, so they would often turn to the development team to fix the issues or rewrite the system.)

So the business areas have recognized this as a way to add value to the company. Now we just need to get the company itself to realize it.

This would give the opportunity for the business areas to have access to actual developers who can deliver functionality quickly in a supportable way.

Wrap Up
I really like the idea of No Estimates, and I hope that it gains traction. There is a lot of trust required between the company and the development teams (but I've wanted to have better integration between the company and the development teams for a long time -- that trust is needed anyway).

It was an eye-opener when I realized that the business areas had already implemented their own version of No Estimates by having a Shadow IT person on staff. Next, we need to figure out how to formalize this so that the right people (developers) are doing the right work.

Happy Coding!