Hopemongers. Find a project. Give $10. See the impact

DevChix

search blogs

posts on this page

archive

RSS 2.0 | Atom 1.0 | CDF

Sign In

# Friday, July 03, 2009
Friday, July 03, 2009 2:37:13 PM (Eastern Daylight Time, UTC-04:00) ( career | programming )

There has been much talk lately about developing software, learning software, skill levels, drag and drop demos and what is Microsoft’s responsibility to the .Net community.

I don’t think Microsoft is responsible for developers’ knowledge or programming skill level. They create tools that can be used for development. That is all we need from them. There are other tools and languages to use and there will be many more in the future.

I think some of the responsibility of quality software development lies with the companies that hire developers for development. You get what you pay for. Companies need to hire talent and provide resources for those developers to continue to learn. Software evolves as does other technologies. Continuous Improvement is not just a buzz word. It does not happen on its own; it takes leadership. It is also vital for the software community to take responsibility for building a better community.

If a developer writes an application by drag and drop that produces code that is un maintainable who is at fault? Have they been taught another way? Are there expectations of design for maintainability? Have they ever had to maintain code another has written? Should Microsoft have warned them in a sales demo that that it might not be the best way to write code? Has someone reviewed the code and the design? Have they been provided the necessary resources to perform their job? Do they have someone to ask how to make it better?

Writing good software is hard. It is not a job for beginners. Microsoft provides the languages, compilers and tools used to write .Net code. If a developer does not know how to write code and isn’t being taught how to do it better they are not really developing software and they certainly aren’t going to become expert or master at their craft.

Anyone can throw flour, salt, sugar , yeast and water into a pan and put it in an oven. It will not become bread unless they followed a good process and knew what it takes to make a good loaf of bread. Often they will have been taught by someone else to bake bread or they will have spent considerable time experimenting until they get it right. They do not go to the appliance store for a salesperson to demonstrate the oven’s new and shiny features to make better bread.

We are becoming a more drag and drop society. I can throw a frozen bag of vegetables into the microwave push a button and have hot steaming vegetables to serve. I did not have to select quality vegetables from the store. I did not need to know how to wash them or that I should and why. I did not have to know how to trim them and prepare them for cooking. I didn’t even need to get a pan dirty.

Software has not reached this level of maturity. I need to understand the details and syntax of the programming language. I need to know how to interface with the operating system. I need to know what the operating system is capable of. I need to know what functions the framework provides and how to make good use of them. I need to understand how to communicate with all other software I need to interact with. I need to know all of this in addition to learning the application domain and what the software is supposed to do.

Software development techniques do need to mature – it should be easier to put a system together. We should not have to spend so much time reinventing the wheel and writing plumbing code. There needs to be a better way to find out what components are available and when they should be used. If we need to buy controls from several different venders to build the best software in an efficient and timely manner then we should be able to and given a means to do so.

My husband is an RF design engineer. He designs all sorts of radio devices and components that go into larger systems. If he had to design every chip, filter and capacitor anew for each project he would not get anything built. He spends considerable time modeling the interaction of these parts on the computer before he decides what will go on the boards and how they should be arranged. He then builds up a prototype and tests it’s functionality. Often things do not work they way they should; there are stray signals and what not (not my domain to explain well) interfering with the functionality. It is a highly iterative process – he goes back and forth between modeling and design and testing in the lab many many times to get it right. He tries many parts out; some are rejected – sometimes they do not make the specs they are designed for in the environment he places them in. Is this the fault of the part designer? No, they can’t possibly imagine every situation where their parts may end up. It just means he needs to change the design to make the part work or find a new part.

He has spent dozens of years becoming an expert in his field. He had mentors from the very beginning guiding him. He cooped during college to get vital real-world experience. He now makes sure to bring in coops to work with him as he knows this is how good engineers will be grown. Yes it takes time away from his work but it is important. He knows that they will not learn in school all that they will need to be successful. He does not expect an engineer with just a few years experience to be able to produce a good product on their own. It takes time to nurture and develop talent.

What will the software community do to find, nurture and develop talent?

Maggie++

Friday, July 03, 2009 3:03:32 PM (Eastern Daylight Time, UTC-04:00)
Great post, Maggie. This is definitely the current challenge we are facing in the industry today. The Software Craftsmanship movement, which you linked to, is focusing on this. It will be interesting to see how the different spaces start to address this.
Friday, July 03, 2009 4:58:52 PM (Eastern Daylight Time, UTC-04:00)
Interesting post.

"If a developer writes an application by drag and drop that produces code that is unmaintainable who is at fault?"

I say the developer. But if a big corporation that makes the tool that almost every .NET developer uses, chooses to convince devs to use it by adding wizards, code generators, and drag-and-drop components, aren't they at fault? Microsoft has rarely shown any leadership in helping the common developer do anything resembling craftsmanship.

In other words, why was VB invented? Certainly not to induce the kind of professional approach that your husband, for example, clearly demonstrates.

I agree MS devs are responsible for their careers. But Microsoft could be doing a lot more to help, too.
Friday, July 03, 2009 6:43:44 PM (Eastern Daylight Time, UTC-04:00)
I guess my point is that there is a lot more to writing software than using a tool.

I agree that Microsoft could certainly choose to become a leader and provide in-depth training for writing better software with its tools. It would make them stronger and help projects built on their framework to be successful. But if they don't we shouldn't just complain that others write bad software because Microsoft showed them a bad way. If they haven't shown this leadership thus far then why do we expect them to be able to now and do it well.



Friday, July 03, 2009 8:49:19 PM (Eastern Daylight Time, UTC-04:00)
2 reactions from reading your post:
1) From Davy Brion's post - I /do/ feel like an alternative .net developer because I'm doing TDD, using IoC containers, open source tools, etc. I've worked several places in my career that still do tons of drag and drop.

2) What is going to change the state of the art in software development? I think that companies who are financing development efforts are going to eventually get sick and tired of paying for poor quality software that needs to be rewritten time and time again. In response, mature software development organizations will rise up to meet this market demand and will become renown for their ability.

What makes a mature software development organization? A shop that will employ only the most senior developers - and will invest in the ability to keep the team intact. Many managers underestimate the power of a team that has grown together and perpetually gain collective knowledge. In my opinion, this is where we need to get to move our industry forward.
Friday, July 03, 2009 10:44:10 PM (Eastern Daylight Time, UTC-04:00)
Thoughtful post. I haven't been in the Microsoft world for about ten years, but even back then, people complained that VB and the like made it too easy to write horrible code.

What they really meant was that the people who did bad VB gave good developers a bad name. I think that's still true, and that's still the crux of the problem. Most people who don't do Microsoft development think that anyone who does just drags and drops and wizards their way to really awful software. Of course that's totally untrue - but Microsoft's low barrier to entry means that often the voices of great developers are overwhelmed by those of the unwashed masses.
Saturday, July 04, 2009 9:41:47 AM (Eastern Daylight Time, UTC-04:00)
Steve,

Agree with you. It is the survival of the fittest and there is room for improvement.

I don't agree that shops should only employ the most senior developers. I think they should employ great developers at all levels and provide mentoring opportunities.
Saturday, July 04, 2009 10:06:53 AM (Eastern Daylight Time, UTC-04:00)
Sarah,

Thanks for the comments. Bad developers go give good developers a bad name - that is true in every profession. I don't really understand the big divide among developers. I think more conferences like CodeMash help to bridge it and the developer communities can do more.

I don't consider myself a Microsoft developer. I don't work for MSFT; I am using their tools and compiler as my current project is in C#. In my early career, what language would be used on a project wasn't even a factor in hiring. We looked for strong problem solving skills, ability to learn new systems quickly, and ones who could think on their feet. At each of the three jobs I had BK I did not know what operating system we would be using for development - it just wasn't the issue - the development environment was not the production environment. We chose the best tools and language for each job individually.

In the 21st century this is no longer the case - you must 'choose' to join a camp and narrow your job search to one area to compete.

I have never worked with drag and drop programmers and have never used VB. My work has always been in engineering and not IT. I would probably feel differently if I had worked in that environment.
Saturday, July 18, 2009 12:19:10 PM (Eastern Daylight Time, UTC-04:00)
Great post! I really enjoyed all the links.
Comments are closed.