Rants Tagged with “Working”
1 (Total Pages: 1/Total Results: 6)
I've spent a lot of time the last few weeks looking at some of the new buzz words in software development. Domain specific languages, dynamic languages, TDD, DDD, *DD, etc.. Most of these ideas have definite benefits to the work of software development but I think they miss the mark on what is really hard in software.
In most projects I've worked on the past twenty some-odd years, the hard part is not how to architect a project, not how to tune a database and not how to eke out every CPU cycle of a function call. In fact the hardest part has always been in understanding how a business does business. There are many names for this but I like to think of this as domain specific knowledge. It's the time in the meeting room with the business veterans (stakeholders of one sort or another) that understand how it really works. Whether that is how freight is shipped across country, how users register with forums or how those scanners at the grocery stores actually work; in all cases these stake holders already know how they do or want to do their job. It is our work as developers into transitioning that into actual software.
Eric Evans talks about this in his Domain Driven Design book, but I think some readers of his book seem trapped into thinking that the magic of the domain is the top-down design of a system. In my opinion they are missing the point. Turning domain knowledge into a system is hard work, no matter what design methodology you use.
It's a people problem. We engineers talk in terms of code, architecture and data. We have our private language that helps us communicate. If you don't think that's true, ask your spouse/partner what happens when they hear you talk about work with your friends. The thing is that in most industries this is true. When you talk to stake holders, they have their own language too. Our job is to pull that information from them and translate it into software designs. Often a small misunderstanding can be the cause for large changes in a system. Getting this knowledge transfer right is crucial. For the most part we do an admirable job of it, but I think it is critical to understand how essential this is. Constant communication with the eventual users of a system is a key to the long-term success of any project.
So, if you've stayed with me this far we're probably in agreement about the importance of domain knowledge. Here's where I get incensed. So much of development these days is being done by outside developers. The strategy of business to keep developers around has vanished. This is evidenced by off-shoring, outsourcing and contractor-based development. Companies are attempting to cut costs by using cheaper developers as well as development teams they can cut loose once a project is complete.
The problem with this strategy is that all the domain knowledge is leaving the enterprise. Companies spend a lot of money for a project and some percentage of that money is in teaching the development team about the problem domain and the way that the company does business. By having short-term development strategies all this knowledge isn't being recouped by the companies. I don't think they understand yet what a bad deal this is for them. But it's not just bad for companies, it is also bad for developers.
In some sense we developers are part of the problem. Quitting your $75K/yr job to be hired back at $75/hr seems like a good deal, but in fact it is not a good deal for either party. Your loyalty is to the paycheck and when you leave, the domain knowledge goes with you. This extra knowledge can help if you stay in the same industry but that's pretty rare. Usually you go to a new type of company and spend time 'ramping-up' on how they do their business. This seems bad for developers because most of the ones I know have passion for technology. They want to be part of a winning team. By being a well-paid mercenary it becomes easy to not care about what you are doing. At the end of the contract you just move on, forcing you to divest in a personal stake. I miss that part of this business. I have had more enjoyment about projects that didn't work than all the mercenary positions I've ever held (yes, I am looking at you Gen<X>).
The dirty little secret in my house is that I'd give up my business and go work for a company if I could believe in them and believe that I was part of something special. In some ways I think most developers are like that. But in this atmosphere of short sightedness, it just doesn't exist.
So do I have a call for action? No. I think that domain knowledge is an important idea that both developers and companies need to address, but I don't have a nice and tidy solution. This is a shift that I think has to happen in software development. Both sides of the table need to look long at the last five to ten years and determine if what we're doing now is better than before. Does it only feel better because each line of code is cheaper to produce (mostly a product of better platforms, not better coders). I hope this can change.
UPDATE: Here's an interesting link that has a different opinion of this subject:
http://thedailywtf.com/Articles/Up-or-Out-Solving-the-IT-Turnover-Crisis.aspx
While this link has gone through many other sites already, I wanted to inlcude it here to make sure every dev in the world reads it! It is an excellent list of the types of influencers that have made me decide to quit being an independent in the past and try to be an employee again. If you are workign for someone else, print this out and leave it on their desk. Its important that non-dev's read this and understand it.
It's been a good time with Magenic these last eleven months. I have thoroughly enjoyed the client's I have dealt with and really got a kick out of the community of consultants, both in Atlanta and nationally.
But I have been itching to go back to being independent. Starting June 1st, I am putting my slate back out and becoming an independent again. I look forward to being able to do more user group talks, training sessions and hopefully more writing in the coming months.
Keep a lookout here for my comings and going in and around the development community.
I wasn't too surprised to read that tech executives were getting tutoring on technology. What really surprised me is that they wanted to keep it so quiet.
Who do they think they are kidding. Their job isn't to understand the technology, but to get people excited about the possibilities of the technology. Anyway, are Palm Pilots that difficult to figure out?
On other note, it seems that I've been bad mouthing a technology for a while for no good reason. I recently purchased a couple of the new Microsoft wireless mice and so far I am really impressed. I am not convinced that horizontal scrolling is that cool, but the mice are extremely responsive. Time will tell if their promised six month battery life holds out to be true.
I finally finished downloading Office (System) 2003 from MSDN and found out that it did *not* include OneNote. It is like breaking a toy on Christmas morning. I admit I am one of the converted. I just love using it for a multi-tasking note taker. I don't just use it in meetings (which I have very few of any more), but all day. As I get an idea about something I am not working on immediately...it goes in OneNote. I just noticed that the MSDN website says the rest of the Office System will be available October 1st. Arg!
I have been spending a lot of time writing about technology lately. After a phone conversation with Tim Ewald, it got me thinking. During the first half of writing the book, I was working full-time writing ATL/C++ apps mostly and trying to get up to speed with ADO.NET at night. While my girlfriend minds, I don't really.
While in this phase of the project, I learned a lot about the technology and the class signatures, but it was very hard to grasp the big picture of the real problems that people will/are facing.
Soon after I got a full-time position developing a large scale .NET application. This really helped me appreciate the nature of the techology. I started to get really excited about how ADO.NET would help people solve these problems. Later on I started doing a tour of .NET User Groups to talk about ADO.NET and this was enlightening as well. People were asking me real-world questions that I did not always have great answers for. In the end, both of these experiences definitely helped me write a better book IMHO.
So the quandry, do I go out and try to find a position helping build large scalep projects to stay sharp with the trench warfare that is coding or simply move to being a full-time writer/editor? I don't want to lose my edge of understanding the code, but trying to do both is exhausting.
In the end, I hope to find somewhere in-between. Work on designing large scale projects while being able to write/edit about feels like the good middle ground.
