Lazycoder

30Jun/1012

The hardest part of software development has nothing to do with code

People who complain about how much “more” code they have to write in an MVC project versus a Webforms project, or really any project, prove to me that they have absolutely no idea where the REAL work is in ANY development project.

The main work in any software development project is FIGURING OUT WHAT TO BUILD. How you build it is trivial compared to the amount of time and effort you SHOULD put into discovering the users needs and working with them to solve their problems and make their life better.

Remember, that’s the number one purpose for any piece of computer hardware or software. This cannot be stressed and repeated enough.

COMPUTERS SHOULD MAKE OUR LIVES BETTER!

How do we write programs that make lives better? By writing programs that fulfill their needs and ease the pain of their work. We still aren’t at a point where we have a common, easy to understand vocabulary when it comes to build software. We often get it wrong the first, second, and third times. That’s where the discipline and engineering comes into play.

Filed under: Agile, General, MVC, Tutorials 12 Comments
3Nov/096

Dependency Injection and Inversion of Control are not rocket surgery

I see a lot of people talking about how “advanced” techniques like dependency injection and inversion of control are and how their team won’t understand either technique.

 

Folks, this isn’t hard. In fact, both of these things are so simple I simply call it “using the programming language”.

 

Let’s look at dependency injection.

PLAIN TEXT
C#:
  1. public class MyClass
  2.     {
  3.         private DataTableReader _reader;
  4.         public MyClass()
  5.         {
  6.             _reader = new DataTableReader(new DataTable());
  7.         }
  8.         private void DoStuffWithTheReader()
  9.         {
  10.             while (_reader.Read())
  11.             {
  12.                 //do fun stuff with the reader.
  13.             }
  14.         }
  15.     }

See the reader variable? That's a dependency. You have to have it in there to do fun things later on. But we have to create it ourselves, which is one more thing that we have to do in our class constructor. In reality we also have to populate the DataTable. So what if we make the reader variable constructor parameter so that another class can do the work of creating the DataTable and the reader?

PLAIN TEXT
C#:
  1. public class MyClass
  2.     {
  3.         private DataTableReader _reader;
  4.         public MyClass(DataTableReader dataTableReader)
  5.         {
  6.             _reader = dataTableReader;
  7.         }
  8.         private void DoStuffWithTheReader()
  9.         {
  10.             while (_reader.Read())
  11.             {
  12.                 //do fun stuff with the reader.
  13.             }
  14.         }
  15.     }

There, that's better. Now our class doesn't have to worry about creating the reader and the DataTable. This, in a nutshell, is dependency injection. It's not very complicated is it? We've made our class construction a little simpler and if we want to unit test this, we don't have to do any complicated mocking, we can just new up our own DataTableReader instance and populate it with whatever test data we want. If you run into any funny looking data in the DoStuffWithTheReader method, you know that you don't have to look in this class at all to see where the funny data is coming from, only in whatever method is creating this class and passing in the DataTableReader.

Now is there anyone who thinks that developers on their team would have trouble understanding passing in a parameter? Should they really be a developer if they do?
Honestly, it's not that hard.

Ok, so let's look at inversion of control. The original definition of inversion of control I read was by Martin Fowler:

There's a big difference now in the flow of control between these programs - in particular the control of when the process_name and process_quest methods are called. In the command line form I control when these methods are called, but in the window example I don't. Instead I hand control over to the windowing system (with the Tk.mainloop command). It then decides when to call my methods, based on the bindings I made when creating the form. The control is inverted - it calls me rather me calling the framework. This phenomenon is Inversion of Control (also known as the Hollywood Principle - "Don't call us, we'll call you").

If you look at the previous example, you'll see that we have already inverted the control a bit just by using dependency injection. But the class still has a degree of control over WHAT concrete object is created, in this case a DataTableReader. What if we need to switch over to a SqlDataReader or an OleDbDataReader? Well, we could create three other classes that all take the specific type of data reader we might want to use. But that's a bad idea, you end up with the same logic spread all over the place. Instead we can use the IDataReader interface that all three classes implement.

PLAIN TEXT
C#:
  1. public class MyClass
  2.     {
  3.         private IDataReader _reader;
  4.  
  5.         public MyClass(IDataReader dataTableReader)
  6.         {
  7.             _reader = dataTableReader;
  8.         }
  9.         private void DoStuffWithTheReader()
  10.         {
  11.             while (_reader.Read())
  12.             {
  13.                 //do fun stuff with the reader.
  14.             }
  15.         }
  16.     }

Now our class not only doesn't have to worry about creating the DataTableReader, it doesn't even really care if it gets a DataTableReader at all. All it cares about is that the reader is referencing something that implements the IDataReader interface. This is a type of inversion of control. Most of the time people get confused between inversion of control and a container that enables inversion of control and dependency injection (like Ninject, StructureMap or Unity). You don't have to use a container to utilize these two techniques, it just makes it a little easier.

update:Also check out this great post "It’s all about the delivery"

update: I mistakingly thought it was hard to do D.I. in Python due to the inheritance mechanism in Python. Turns out, it's just as easy.

PLAIN TEXT
PYTHON:
  1. class MyClass():
  2.  
  3.     def __init__(self, dataTableReader):
  4.         self._reader = dataTableReader
  5.        
  6.     def DoStuffWithTheReader(self):
  7.         while(self._reader.Read()):
  8.             #Do Fun Stuff with the reader.
  9.             print(self._reader.item)

Tagged as: , , , 6 Comments
29Oct/090

Agile practices do not address technical complexity

So, first go read Ted Neward “Agile is treating the symptoms, not the disease.” and Phill Haack “Software Externalities” then read the Agile Manifesto

At some point that very simple manifesto turned into a set of “must have” tools, technologies, methodologies, and processes. Which I think defeats the purpose. You have to look at each tool and methodology and think “how does this help me build better software for my user?”

There is a very important paragraph at the bottom.

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

 

So let’s go through each line.

 

Individuals and interactions over processes and tools

These “story cards” are one way to increase the communication between individuals during their interactions. Gigantic requirement specifications don’t do anyone except other software engineers any good. The daily standup meeting that a lot of agile practioners adopt is one way to keep the team up to date and find out about possible problems as soon as possible.

 

Working software over comprehensive documentation

No matter what, you’d rather have an application that meets the users needs and helps them get stuff done easier than they could before you wrote their application. Chances are, if you need to write a lot of documentation, you’ll have to maintain it also. Most of the time documentation is only for other developers that will have to come along behind you and change the software to meet new user needs. What better way to communicate what the software is supposed to do than a bunch of executable code, e.g. unit/scenario/integration tests, that ensures the application does what it says it can do?

Customer collaboration over contract negotiation

By adopting techniques and tools that allow you to change direction quickly and confidently, you don’t need to “lock down requirements” before you start developing. If the requirements change, you’re code base and tools are flexible enough to handle the change. That’s where principles like S.O.L.I.D. come into play, they make your code base more flexible and responsive to change.

Responding to change over following a plan

How can you ensure that, as you change your software to respond to changes in the business or requirements, your software doesn’t break? Automated testing is one method. Continuous integration builds are another. These tools aren’t used by agile practitioners  because they want to feel cool, they are used to help them better respond to change. The story cards and backlog also help. You can re-prioritize your backlog to meet the businesses current needs. Since your iterations are short, and your stories are small, the overall impact to changing direction is minimized.

 

The fact that software development is complex, and that there is a lot of new things to learn. That there is ALWAYS something new to learn about software development, has NOTHING to do with agile practices. You’d have exactly the same problem keeping up if you practice agile or not. You might have an internal process where you work that allows you to respond to change quickly, it may even involve Microsoft Access!

There was a great post that Miguel De Icaza linked to on Twitter. “Every Ideology is Right”

What I mean by "right" is that is each one is responding to a genuine problem within human existence. And their prescriptions for how to deal with that problem "work," at least in the short term in limited circumstances.

Obviously, there are unforeseen consequences because each ideology looks at a limited aspect of reality, and then tries to apply its solution for that part of reality to ALL of reality. The important thing is to try to have your ideology "look" at as much of reality as possible.

Tagged as: No Comments
30Sep/0910

Sure you’re agile, what about your QA department?

For the past 14 years I've been a software developer for money, I've noticed a trend. The QA department finds the most bugs towards the end of the release cycle. Even when I've worked in departments that are supposedly following an iterative development process.

A lot of the "bugs" revolve around "fit and polish" issues. Making sure the font and wording is correct in all locations. Making sure the application looks and behaves the same across all platforms,browsers in the case of web applications. Most all requirements documents or stories include a note for the QA department to perform these checks well in advance of the final launch, yet these bugs always seem to come up and they usually are not regression bugs.

The places that follow an iterative cycle I've found don't really deploy after each iteration to any meaningful customers. They are all still tied to the "big launch". I think that getting the product into the hands of people who ACTUALLY care about it, rather than the ones that are just concerned about the launch, is crucial to delivering a high-quality product.

I'm wondering if the traditional QA department is a relic that we need to get rid of? If we move all of the testing/bug finding to the interation and fix them immediately, isn't QA relegated to mainly verifying bugs reported by customers/users?

So the question is: How do we get QA more involved in the process?

Filed under: Agile, Process 10 Comments
31Jul/0911

Structure and composition of agile teams

I've been thinking a lot lately about how agile teams are composed today and how they typically work in a workplace that is practicing agile. I've only been "living the agile lifestyle" for a couple of years now, at first all by myself(?!) and the past year and a half with agile teams.

One thing that I've noticed about the agile teams I've been a part of is that they are mostly composed on unitaskers. That is, they are composed of developers, who only write production code and tests, some sort of tester, who only test the production code, and project managers/project owners, who define the requirements

The way I've seen these teams work is that the PM/PO writes up a story, then the testers and developers ask the PO questions about the story and make suggestions/clarifications. Then the developers starting writing code while the testers start writing test scripts. Once the developers have finished the code and pushed it to a test environment, the testers test the code, report bugs, and the developers fix the bugs. Eventually, the code settles down and all the team members agree that the story is complete.

So it seems like all the team members are busy all the time, but if you read between the lines you see a lot of waiting. The testers are waiting for the developers to finish writing the code and deploy it to the test environment. Then the developers are waiting for the testers to finish testing so they can either fix the bugs or demo the code to the PO and close the story. The PO is usually waiting for everyone to finish their tasks so they can see the demo and close the story.

I've been toying with the idea of all developer teams. As the interation progresses, the developers pair up on stories, fixing problems as they go. Then the developers swap off and test the other pairs stories, fixing any defects they find as they test. To cut out the lag from deploying to a test environment.

We've also had some success pairing up developers with QA during development and testing where I'm working now.

What do you think?

Filed under: Agile 11 Comments
   

The Lounge

TwitterCounter

120x60-1

What I'm Doing...

Powered by Twitter Tools

Books I’ve worked on

Contributors

Links

Delicious  FriendFeed  Last.fm  LinkedIn  

RSS Herding Code Podcast