mibuso.com

Yes it is, it always is about learning. If you deliberately stop learning you WILL miss the boat at some point.


Whether you print to a piece of paper or a digitally rendered layout, the layout itself will still need to be designed.


Not on a personal level, but from an organizational standpoint heck yes I always want to be better than the competition, I always want to learn the new stuff before the other guy. Maybe not always ME but certainly someone in my organization


Hands-on, what does that mean anyway. Whatever I do I am hands-on with it. Hands-on consulting, hands-on business analysis, hands-on performance troubleshooting, hands-on design, hands-on whatever. The reality is it there's another 25-30 years to go before I can retire, so I better keep up with current technology if I want to stay relevant. I don't mind at all, I like the challenge.

Maybe you want to stop evolving, but that will make you an old man by the time you are 50

The point I was trying to make was that people are artificially holding on to the existing report designer it seems because they feel that learning the new one is too difficult. All I am saying do so at your own peril because everyone else will be miles ahead of you before you realize that you are behind.

Hi,



Indeed. But in which direction? I must say that my encounters with RDLC were all awful, although I've got it working after a while. I'm not sure about throwing away the thing that at least worked... like the reports in Navision 3.56 It's the same for the classic reports.

with best regards

Jens

Does it matter which direction? Unless you are going to develop your own ERP product that works better, there's not a whole lot you can do about it. Yeah it's a lot of work, and yes it is very different, but once you do learn, it's not so bad, and I've heard a lot of folks say that they actually like the Visual Studio report designer much better than the old NAV report designer, once they got used to it.

I'll tell you this much: those who DID invest in learning how to develop RDLC reports, and those that DID help their customers develop them, those that did NOT take the easy way out, all of those companies are now at a HUGE advantage with NAV 2013 coming out later this year.

I agree.
Visual Studio offers a lot more features and functionality and NAV 2013 will remove most of the clunkiness for the developer.
Hopefully the users will take advantage of the interactive capabilities of the new reports and save a lot more trees.

Generally I find they lead to more readable, cleaner, maintainable programming.

Consider a report as Items in lines, and in columns this weeks sales, this month, last month and YTD. With FlowFields, it is looping through Items, setting Date Filters and CalcFields. You don't have to read the entry table. This way it is short, succint, readable, making the numbers bascially a "property" of the master data record which IMHO is clean and logical, because in real life we can consider a "sales" as the property of an Item. The SQL way would be to go to the entry table and SUM and GROUP which is not as clean IMHO because we don't work on the same conceptual level as in real life (in real life we consider sales as a property of an item and not as the result of a sum of entries).



OK this is what in my experience never works. I am in favor of everything done by programmers although not necessarily everything done by programming (as configurable solutions are cleaner). I think this is a dream that works at some companies at best. I know many managers who don't use Navision, they want reports mailed to them. If they use it, they don't want to configure them, at best they just want to click a button. The folks in admin, sales, accounting generally don't want to configure reports either, because even if it looks easy they usually don't want to take responsibility for them. When the manager sees a strange number and ask why is it that they don't want to be held responsible. They tend to delegate it to IT an IT tends to delegate it to external consultants or hire an internal one for a larger organization. However many organzations don't even have IT they demand that external consultants provide them with ready reports.

At any rate, of course easily configurable solutions are often useful, so that you can delegate some jobs to a junior consultant or internal IT.

But only if everything configurable is also modifiable infinitely by code, because managers often have requests that outstrip the limitations of every possible too. Note that I am not talking about business requirements in the school sense. I am talking about personal requirements that came from the personalities of people. For example a manager who used a previous reporting tool in his previous job might demand that his reports look the same, for convenience's sake. (I even had requirements of simulating parts of the UI of another accounting software in order not to have to retrain people.)

Given the almost infinite ways requirements and expectations can outstrip the limitations of any tool, I am quite in favor of DIY solutions by people who can program, these should be configurable and not every single thing hardcoded, but still anything and everything must be modifiable by code. This can cost in the longer run more, and in an ideal world where people were rational and personal requirements would be equal to sensible business requirements, and thus expectations could be managed, we would avoid it. But in the real world populated with real people driven by habits, emotions, personality traits flexibility is the only way to keep everybody happy. Even if costs more in the longer run. (Actually a lot of managers prefer more costs in the longer run than an investment up front. Liquidity logic often beats investment logic in todays liquidity-scarce world.)

I will reformulate my question. No matter how good we are, we at the lowest level of the hiearchy because we do hands-on technical work instead of just managing people. In every corporate hierarchy the bottom level is the people who work with things (like software), who get things done directly, and above them there is a hierarchy of managers who manage teams, departments, divisions etc. who work with people. So naturally after doing 10 years of hands-on work I am thinking it is time to start rising up and you know actually begin having a career, one ladder step after the other, into management, instead of spending my whole life with technical hands-on work. And of course at a certain level in management it does not matter much with what technology you work with, Navision or SAP, Classic or RDL reports, you leave that for the people on the bottom level, you just manage concepts, deadlines, teams etc. My question was - do you think it is not realistic, not possible, or do you simply personally don't wish to do that? I do consider consulting/programming as a temporary springboard for gathering experience and the trying to shoot for a management job. I am asking this because I don't know whether it is really realistic to have an old-fashioned ladder-climbing career out of the realms of hands-on technical work and into pure management, or really this is something of the 1980's and not applicable anymore. I do find it is very hard and had no success with it so far, I don't know if it is realistic at all. (I am thinking about large end-user companies, not consulting companies who tend to be small, hence no career. This is part of the reasons I switched to the end-user side.)

I don't know how you jumped from a discussion about reports into asking for career advice. Especially that little bit about switching to the customer side and the size of the company is fascinating stuff. Let me circle back to the report thing though and try to keep this discussion relevant to that.

It seems like you think whether to use the new technology is not relevant in your stage of your career. The way I interpret your thoughts here that you're choosing to no longer concern yourself with those details because you want to move up the ladder and let other people worry about that. To me that almost sounds like you think that at some point you get to work in an office with wood paneling, and really have all the underlings do the work, all you need to do is hold them to deadlines. In my opinion that is exactly what makes you not management material. The higher you climb, the harder you have to work, and all of a sudden it's YOU that makes the decisions, and "I've done enough programming, I don't need to think about new technology anymore" is not something that someone in management should be thinking. And don't even think about whether you at the customer side of things should be bothered, I personally think it is even MORE important to be aware on that side, because now NAV is not the only thing you do anymore and it has to fit into the rest of the technology ecosystem.

The decisions on what technology to use to grow as an organization is not made by the programmers. It is management that determines whether to hold on to old technology (because it is inconvenient / difficult / costly to learn the new technology) and where to invest in new technology. I would say the more you are in management, the MORE relevant it becomes to stay up to speed of all the new things. Maybe not every single little detail, but you certainly need to stay aware of what's going on. YOU need to be informed if you're the one making the decisions.

I'll say it again:

That doesn't just apply to RDLC reports, that applies to any new technology.

Actually this is a very interesting and very important discussion, but it does need to be split out and started as its own topic, not added in to something as trivial as reporting.

The bizarre thing here is that this is the first time I remember ever in a thread where something at the same time tells me that I agree with Miklos and disagree with Denster.

I suggest everyone who hasn't yet, read the Peter Principle.
It is an amusing book about what happens at many companies - people rise to their level of incompetence.

The decision about whether to move into management should be based on whether you will enjoy it (working for the next 30 years at something you hate is not a wise decision) and whether you will actually be good at it.

Take some time to consider this before you make your decision.

Remember that 10 years out of hands-on working with technology will make it hard to move back.

I haven't read that since I left Uni. Might get a copy and re-read it.

Same here.

I'm very surprised about that. Which part that I said do you disagree with?

It's not that I completely disagree with you, I just agree with Miklos more.

From my perspective (and only mine alone), my sole dedication is to my customers. I don't really care about the technology and I don't care about being the best programmer or how "good" I am. I believe if we can deliver the best solution for the customer, regardless of technology, that is what we owe to our customers.

In order for partners like us to deliver the best solution, if technology is needed, it has to be easily implemented. I do realize the term "difficulty" is relative, however, comparing RDLC reporting to Jet Reports and/or Pivotier you don't have to be a programmer to see which one is more difficult to implement.

I'm all about learning new things. In this specific case, learning RDLC is like taking step backwards. I don't feel like learning RDLC will make me a better programmer or implementor. Furthermore, I don't believe learning the new RDLC will make our clients better off than they were yesterday.

By the way, my response is not to the part about career advice. Everyone has their own preference on how they want to live and how they want to die. The important things, again for me at least, is to have as few regrets as you can when you lay on your death bed.

Hi,



Yes that's true. But in my work experience, those decisions made are - to be polite - often not in the best interest of the company. That's what I learned over the last 20 or so years: Getting management informed is a tough job, it is an art form to present decision paths that work. Lots of the decision makers don't keep up to speed with changing technology, often they do fall for marketing hype and buzzwords, with sometimes fatal consequences. That's part of the reason why so many crap software installations are around. In this spirit, calling NAV 2009 RTC with RDLC as "fit for business" is ... well ... not what I'd call it. And I've done my share on pages and RDLC coding. Using it is an expensive decision in the long run, IMO.

I know it sounds a bit off-topic, but looking at the title I think it's not.

with best regards

Jens